Question 1

What is Palma.ai in one sentence?

Accepted Answer

Palma.ai is the enterprise governance layer for MCP — it gives every person and agent a single governed connector carrying the tools and Skills they're entitled to, enforces policies on the actual arguments of a call, pauses high-risk actions for human approval, and records everything in a tamper-evident audit trail with cost attributed per agent, team and business unit.

Question 2

How does Palma.ai relate to MCP?

Accepted Answer

MCP (Model Context Protocol) is the open standard for connecting AI agents to tools — adopted by Anthropic, OpenAI, Google, Microsoft and AWS, and now stewarded under the Linux Foundation. It's becoming the universal interface between agents and enterprise systems, and thousands of MCP servers already exist in the wild. Palma doesn't replace MCP — it adds the enterprise layer on top: identity, Skills, policies, approvals, audit, and cost control. Think of it as the control plane for MCP.

Question 3

Who is Palma.ai for?

Accepted Answer

Palma is built for enterprises moving AI agents from pilot to production. The primary buyers are CISOs and security teams who need governance and compliance proof, platform teams who need a centralized control layer, and CFOs who need cost visibility. Day-to-day users include platform engineers, AI/ML engineers, security and compliance teams, IT/identity teams, and finance.

Question 4

Why do we need a governance layer on top of MCP?

Accepted Answer

MCP defines how tools are exposed. It doesn't define who can access them, what arguments agents can pass, who approves high-risk actions, what happened when something ran, or what it cost. Without a governance layer, every team wires up its own servers and its own credentials, static secrets end up scattered across laptops and config files, nobody can say who can do what, and every agent use case turns into a bespoke security project that stalls at the security review. Palma is the control layer that gets you past it — and it's the difference between three agents in a pilot and three thousand in production.

Question 5

What's a Space?

Accepted Answer

A Space is a governed boundary for one business case — e.g., "Sales Automation", "Engineering Copilot", "Finance Reporting". Each Space defines which tools and Skills are available, who can use them, what policies apply, and how costs are tracked. You scale by adding Spaces, not by rearchitecting. There are two types: Copilot Spaces (for humans in chat/IDEs, authenticated via SSO) and Agent Spaces (for autonomous background agents, with per-agent credentials).

Question 6

What's a Pack?

Accepted Answer

A Pack is a reusable bundle of tools and Skills for a common need — e.g., "CRM Basics", "Dev Workflow", "Observability Read-Only". Instead of configuring access from scratch for every team, you create Packs once and assign them to Spaces. New team, new use case? Create a Space, attach the right Packs, adjust policies. That's how governance scales without becoming a bottleneck.

Question 7

What's a Skill?

Accepted Answer

A tool is a verb — "send an email". A Skill is the playbook that tells an agent when and how to use the verbs it already has. It's a written procedure plus any supporting files: how your team actually closes the books, runs an incident review, or qualifies a lead. Skills are how your best operator's process reaches everyone else's agent.

Question 8

How do Skills reach an agent?

Accepted Answer

Over MCP, so they work in whichever assistant your people already use. Palma serves them four ways: as MCP resources with a discovery manifest, through meta-tools the agent can call to search and load them, as MCP prompts, and as a short Skills summary injected into the connection handshake. The agent resolves them live on every session — so when your team updates a Skill, agents pick it up within seconds rather than running from a config someone pasted months ago.

Question 9

How do you stop a bad Skill from spreading?

Accepted Answer

Skills are published as immutable, content-hashed versions, and only scanner-passed versions are ever served. Secrets are stripped from the content before a version is stored, so a credential pasted into a playbook never persists. Visibility is explicit — private, shared with named parties, or org-wide — and a Skill that depends on a tool can't be attached to a Space on its own; it has to travel in a Pack, so the playbook never lands somewhere without the access it assumes. Note that a tool reference inside a Skill documents a dependency; it never grants access to that tool.

Question 10

Can anyone in the company create a Skill?

Accepted Answer

Only if you turn it on. Personal Skills are off by default for every tenant, and when enabled they serve only their owner — they never reach a colleague without going through your review and placement rules. Anyone using a Skill can flag it, backed by evidence from the run; maintainers triage from a single inbox and whoever raised it is told the outcome.

Question 11

Who is each action attributed to?

Accepted Answer

Every tool call is attributed to the person it was done for, the agent that did it, and the application it ran in — Cursor, Claude Desktop, a custom app, and so on. That means you can answer "who did what, via which agent, running where" for every single action, rather than seeing one shared service account in the logs.

Question 12

What can a policy actually check?

Accepted Answer

Most access control gates at the tool name — "can this agent use the Salesforce tool?" Palma evaluates the actual arguments of the call — "can this agent query Salesforce accounts, but only in the EMEA region, and only during business hours?" Policies can read tool names, glob patterns, arguments, time windows, and caller identity at runtime, and you can test a rule before you ship it. Three enforcement modes let you roll out progressively: observe (log only), warn (log and alert), or enforce (block).

Question 13

What approval workflows does Palma support?

Accepted Answer

Palma supports quorum-based approval workflows: first-approval-wins, unanimous, or M-of-N. Approvals can be triggered conditionally — for cross-team requests, cross-OU requests, or high-criticality resources. SLA tracking, escalation and break-glass are built in. Lifecycle stages (Draft → Dev → Test → Prod) with stage gates ensure nothing reaches production without proper sign-off.

Question 14

What does the audit trail look like?

Accepted Answer

Every tool call is logged with the person, agent, application, tool name, arguments, result, duration, token usage, and cost. Audit data is tamper-evident and verifiable offline with your own key, so your auditor doesn't have to take our word for it, and it streams to the SIEM you already run. You also get a control plane audit log that tracks every configuration change — who changed what, with before/after diffs and sensitive field redaction.

Question 15

How does Palma help with EU AI Act compliance?

Accepted Answer

Obligations under the EU AI Act took effect on 2 August 2026, and penalties are linked to global turnover. Enterprises have to demonstrate proof of control over AI systems. Palma's per-action attribution, argument-level policies, quorum-based approvals, and tamper-evident audit logs provide the evidence regulators require: who authorised what, what policies were in place, and a complete record of every AI action on enterprise systems.

Question 16

Does Palma support SOC 2 and DORA requirements?

Accepted Answer

Palma's tamper-evident audit logs, per-action attribution, quorum-based approval workflows, and policy enforcement are designed to support SOC 2 and DORA evidence requirements. Every action is traceable, every policy decision is logged, and retention periods are configurable. For questions about our own certifications and their current status, talk to the team.

Question 17

Can Palma help us pass a security review or compliance audit?

Accepted Answer

That's a core use case. Palma provides the evidence compliance teams and auditors need: a complete audit trail of every agent action (who, what, when, via which agent), proof that policies were enforced, records of approval decisions, and cost attribution. The single biggest reason enterprise AI pilots never reach production is that security and compliance teams can't approve what they can't govern. Palma is what unblocks them — and it turns a six-month security review into a conversation about evidence you can already produce.

Question 18

How does Palma track AI agent costs?

Accepted Answer

Every tool call is tracked and attributed by Space (business case), team, agent, and user. You can see exactly what each AI initiative costs, set budgets per Space with enforcement, and generate chargeback reports for finance. No more mystery cloud line items — Palma makes agent spend explainable from day one.

Question 19

Can we set budget limits on agent usage?

Accepted Answer

Yes. Budget enforcement is built in at the Space level. Set spending limits per business case, per team, or per agent. Palma tracks spend and can alert or enforce when budgets are approached or exceeded. This is critical as agent deployments scale — without guardrails, AI spend can grow unchecked.

Question 20

How does governance make agents more accurate?

Accepted Answer

This is the benefit most people don't expect. By curating smaller, purpose-built tool surfaces per business case (via Spaces and Packs), Palma reduces tool confusion and context bloat — agents see only the tools they need, which means fewer wrong calls and higher success rates on multi-step tasks. Skills add the other half: the agent isn't just given the right verbs, it's given your team's procedure for using them.

Question 21

Will Palma slow our agents down?

Accepted Answer

The opposite. Governance that standardises policies and approvals at the MCP layer means new agents and use cases can reuse existing rules, Packs, and Spaces — instead of renegotiating security and access on every project. Progressive rollout (observe → warn → enforce) lets you go live safely without blocking development. And curated tool surfaces actually improve agent performance.

Question 22

How is Palma deployed — SaaS, on-prem, VPC?

Accepted Answer

Palma is self-hosted by default — it runs on your infrastructure (Docker, Kubernetes) so your data, credentials, and audit logs never leave your environment, including fully air-gapped. Per-tenant encryption key derivation ensures cryptographic isolation. Palma can also host it for you if you prefer SaaS. Either way, the architecture is designed for regulated industries where data residency matters.

Question 23

How does Palma integrate with our identity provider?

Accepted Answer

Connectors are assigned by IdP group, so a joiner gets theirs on day one and a leaver loses it the moment the group changes — no per-user setup and no credentials sitting on laptops. Palma integrates with your existing IdP — Okta, Entra, Auth0, or any OIDC-compliant provider — with SCIM provisioning and SAML support. Users authenticate via SSO; agents authenticate via client credentials. Palma also manages upstream auth to every MCP server behind it (OAuth, API keys, mTLS, vault).

Question 24

What data flows through Palma?

Accepted Answer

Palma processes tool call metadata: which tools were called, by which agent, for which user, with what arguments, and what the result was. PII and secrets are detected and redacted on the wire, before the request reaches the tool, and sensitive fields are redacted in logs. Payload handling and retention can be tailored to your data residency and compliance requirements.

Question 25

Which agent frameworks and LLMs does Palma support?

Accepted Answer

All of them. Palma is agent-agnostic — it works at the MCP protocol level, so it governs any agent, copilot, or framework that speaks MCP: LangChain, CrewAI, AutoGen, Claude, GPT, Cursor, Claude Code, Windsurf, custom agents, and anything else. The same connector, Skills and policies follow the person into whichever assistant they open. Switch models or frameworks without touching your governance layer.

Question 26

How is Palma different from an API gateway?

Accepted Answer

API gateways manage HTTP traffic — rate limits, routing, auth tokens. Palma governs agent execution: which tools and Skills can be reached, what arguments can be passed, who approved it, who the action is attributable to, and what it cost. An API gateway can route to an MCP server — it cannot evaluate tool arguments, manage approval workflows, distribute governed Skills, or provide cost attribution per business case.

Question 27

How does Palma compare to other MCP security tools?

Accepted Answer

Most tools in this space are built to give a single engineering team of five or ten people a safer way to reach a handful of MCP servers. Palma is built for enterprise scale and enterprise process — the whole organisation, every employee, every agent. It doesn't just show you what's happening, it enforces what should happen. Per-action attribution, argument-level policies, governed Skill distribution, and built-in cost attribution are architectural decisions, not features you can bolt on afterwards. That gap gets wider, not narrower, as you scale.

Question 28

Are we locked into Palma if we adopt it?

Accepted Answer

No. Palma is built on the open MCP standard and runs on infrastructure you control. Your real investment is in well-defined MCP capabilities, Skills and policies, which remain portable. Palma is designed to reduce vendor lock-in, not create more — and because it's agent-agnostic, you can change agents, models, or frameworks without touching the governance layer.

Question 29

How does Palma future-proof our AI stack?

Accepted Answer

Palma decouples governance from any specific agent framework or LLM. MCP integrations, Skills and policies live in one layer; agents and models can be swapped, added, or retired without rebuilding tool access. Invest in governance once — it scales regardless of which agents, copilots, or models go to production.

Question 30

What's the typical starting point?

Accepted Answer

Most organisations start with one or two high-value use cases that touch real systems — e.g., developer copilot access or an autonomous reporting agent. We set up Palma as the governance layer for those workflows, establish baselines for security, cost, and accuracy, and then scale out to more teams and Spaces once the pattern is proven. A first Space can be running in about 20 minutes.

Question 31

What if we're still in the pilot phase with AI agents?

Accepted Answer

That's the ideal time. Setting up governance before you scale is far easier than retrofitting it later. Palma's lifecycle stages (Draft → Dev → Test → Prod) are designed for exactly this — start governed from day one, then promote to production when ready. Don't wait until you have 50 agents and no audit trail.

Question 32

How quickly can we get to production?

Accepted Answer

A first Space takes about 20 minutes: register your MCP servers, Palma auto-discovers the tools, curate them into a Pack, set a policy, and you're live. Full enterprise rollout depends on scope, but the plug-and-play architecture means there's no lengthy integration project — most enterprises go from first demo to first governed Space within a week.

Frequently Asked Questions

General