Security
Agents on real systems, without taking anyone's word for it.
The moment an agent can act on production, the question stops being what a model might say and becomes what it is permitted to do. This is how that is decided, enforced and evidenced.
Posture
Where it runs, and what it never holds.
Most of the security question is answered by architecture rather than by features.
It runs on your infrastructure
Docker, Kubernetes or bare metal, inside your network and in front of your own MCP servers. There is no shared tenancy to reason about and no data aggregation on our side.
Your identity provider stays the authority
OIDC and SAML SSO with SCIM provisioning and just-in-time user creation. Palma is not an IdP and does not want to be one — it reads the groups you already maintain.
Credentials are not handed out
Seven outbound strategies, including RFC 8693 token exchange and vault-held credentials, so a downstream system can be reached without its secret ever reaching an agent or a user.
On every call
Attribution is not optional.
A shared service account is where accountability goes to die. Every request through Palma carries all three principals, so the answer to “who did this” is a person — and the answer to “what happened” includes the calls that were stopped.
- User
- Agent
- Host client
Controls
What is enforced at the call.
Every one of these applies before the request reaches your system, at the single point every agent-to-tool call passes through.
Least privilege, by construction
A tool an identity is not entitled to is not listed to that identity. Access is decided by subject, group and token issuer, before anything is offered.
Approval for the actions that warrant it
High-risk calls pause for a named approver mid-flight instead of failing silently or proceeding quietly.
Argument-level rules
Policies decide on the contents of a request, not just its name — so a permitted capability can still be stopped on a specific value.
Rate limits at the gateway
A looping agent is contained at the point of the call, before it becomes an incident downstream.
Secrets stripped from Skills
Redaction runs before a Skill version is stored, and scanning blocks versions carrying injection, exfiltration or privilege-escalation patterns.
Scoped visibility for resources
Tenant-wide, private by ownership chain, or restricted to a need-to-know allowlist — chosen per resource rather than assumed.
Evidence
An audit trail a reviewer can actually read.
Each entry names the person, the agent acting for them and the client it arrived through, alongside the tool, the server and the outcome. Failures carry their reason rather than a status code.
- User, agent and host client on every call
- Denials and rate-limit stops recorded alongside successes
- Filterable by space, agent, server and status across the org
Attribution
Who did this, answered properly.
Shared service accounts are how attribution dies. Every call carries the chain that produced it.
Three principals on every entry
The user, the agent acting for them, and the client it came through. "Who did this" resolves to people, not to a service account.
Control-plane changes are tracked
Configuration changes are recorded with diffs, so a change to the rules is as reviewable as a call made under them.
Readable by your reviewer
Activity filters by space, agent, server and status across the organisation, so an auditor can answer their own question without a walkthrough.
Questions
What a security review asks.
Short answers, in the order reviewers usually ask them. The longer versions are above.
What exactly does Palma enforce, and where?
Palma governs agent-to-tool calls that pass through its connector: scoped tool access, rules on the request arguments, approval workflows, rate limits, credential handling, and an audit record that ties every call to the person, the agent acting for them and the host client, including calls that were denied or held. Coverage is the governed route; which clients, servers and credentials sit inside it is a deployment decision, and the first thing a reviewer should ask.
What are shadow MCP servers?
MCP integrations in use outside your approved inventory: a server someone wired into their IDE with a personal API key, a community server nobody reviewed, a connector a team set up before there was a process. Most are not malicious. The problem is that security cannot rely on controls it has not reviewed or traffic it cannot see. Reducing the risk starts with an inventory of clients, servers and owners, a review of the credentials each uses, and an approved route for the legitimate use cases.
Can Palma find every shadow MCP server?
No. Palma governs the MCP traffic connected through it and notices when a connected server changes its tools. It does not, on its own, find every unmanaged server on every device; endpoint and network controls cover the bypass paths, and the inventory above is where to start.
Where does Palma run?
On your infrastructure — Docker, Kubernetes or bare metal — inside your network and in front of your own MCP servers.
Do agents ever hold downstream credentials?
No. Outbound authentication strategies including RFC 8693 token exchange and vault-held credentials mean a downstream system can be reached without its secret reaching the agent or the user.
How is an agent action attributed?
Every call records three principals: the user, the agent acting on their behalf, and the host client the request arrived through.
Does Palma replace our identity provider or policy decision point?
No. Your IdP remains the source of identity and groups, and where you run a PDP it remains the authority. Palma is where those decisions are enforced, at the agent-to-tool call.
Book a demo
See what governed AI agents look like.
A 20-minute demo on your stack. We'll show Palma working with the agents, tools and identity provider you already run.
- Enterprise security
- Role-based access
- Instant integration
Latest Blog Posts
Stay up-to-date with the latest in enterprise AI, MCP servers, and secure integration strategies.
