AI Privileged Access Control Plane
In every high-impact MCP incident so far, the tool call was one the agent was authorized to make. The damage came from the scope and lifetime of the credential the MCP server was holding.
Token Ladder · RFC 8693
The TTL ladder is asymmetric on purpose: Ts is DPoP-bound and re-checked against policy on every call, so a stolen copy is waste paper without the private key — it can afford to live longer. Tup is an unbound upstream credential that works for whoever holds it — so it must be the shortest-lived thing on the chain. See the full claim design →
The empirical argument
There is no server-side patch, because the PAT's scope itself is the vulnerability.
Line these up and you get a counter-intuitive but consistent conclusion: none of them was a memory-safety bug, and none of them was a missing approval prompt. In each case the tool call was inside the agent's authorized scope. What turned it into a disaster was that the credential was too broad and lived too long.
That fixes where the control point has to be. Prompt-injection defenses, tool-description pinning, approval dialogs — all of them sit above the credential. They can stop the agent from asking; they cannot stop the credential from working. A poisoned tool description, a compromised npm version, and an infostealer reading ~/.claude.json all reach the same static PAT, and none of them passes through a PreToolUse hook.
Put the other way round: if the credential never lands on the laptop, tool poisoning degrades from “exfiltrate the entire private repository” to “make one authorized, logged, revocable call.”
— that single sentence is the whole design premise of AgentPAMThe problem
Today, everything identifying an AI agent to a sensitive API is one long-lived API key sitting in a dotfile. That static string flattens four dimensions into a single value.
Every downstream control — authorization, audit, revocation — is built on that string, so all of them lose resolution. The target API's log can only say “some token called me.” It can never answer “whose agent, which one, for what task.”
Evidence
These are third-party survey figures, not our own measurements. Verify the sources before citing them.
Self-diagnosis
This taxonomy is written in customer language. Count how many you recognise — then read our answer, and how far our coverage actually goes.
Maximal grants nobody scoped
Our answerRFC 9396 RAR authorization_details expresses fine-grained authorization; MCP incremental scope consent (requested mid-flight via WWW-Authenticate) means no maximal grant up front.
The agent inherits everything the person has
Our answerThe agent receives a strict subset of that person: granted_capabilities ⊆ blueprint ceiling, with the act chain narrowing monotonically. The agent is never equivalent to the human behind it.
You cannot tell what the agent did or why
Our answerAudit carries task.purpose and sensitivity — we actively collect declared intent rather than passively recording traffic, and bind every call to that declaration.
Long-lived credentials sitting on disk
Our answerTier 0 credential custody plus the four-step TTL ladder (Tup 60–300s). There is no standing token because the agent never received one.
The log cannot answer who did what
Our answerA vendor-neutral event schema (human / agent / blueprint / task / tool / resource / decision / obligations / delegation chain), correlated by W3C Trace Context, with hash-chained tamper evidence.
Every platform enforces differently
Our answerA single policy plane across IdPs and clouds. Entra governs the agents inside Entra, AgentCore governs the ones inside AWS — nobody governs all of them.
Developers wire up their own agents
Our answerEMA / ID-JAG moves consent and policy decisions from the end user to the enterprise IdP — no OAuth consent screen, no shadow connections, one revocation point.
Scope only ever grows
Our answerMonotonic narrowing (scope can only shrink) + lifecycle_binding (the task terminates and credentials die without waiting for the TTL) + no scope expansion along the chain.
Why classic PAM does not carry over
PAM has done session recording and time-boxed checkout for twenty years. It does not carry over to AI agents — not because it was done badly, but because three things are missing from its threat model.
CI jobs and microservices can be enumerated and allowlisted ahead of time. An AI agent's next action is decided by the LLM at runtime. Policy cannot just say “may call X” — it has to be able to judge intent at runtime.
Anything the agent reads — a web page, an issue, a log, the return value of the previous tool — may be attacker-authored instructions. So the agent's authorization cannot equal the authorization of the credential it holds. Classic PAM has no such case.
An agent acts on someone's behalf, but is not that person. Classic PAM has only “user” and “service account” — there is no attenuated, scoped, time-boxed persona in between.
human → delegates to → agent instance → brokered to → workload credential verifiable, attenuable, revocable, and auditable.
Identity model
“Short-lived tokens” and “durable agent identity” are not an either/or — they live at different layers. The instance persists to carry policy, sponsor, and audit history; the session is minted per task to carry on-behalf-of and task scope.
What this kind of agent is and the most it may ever request. Credentials hang off the blueprint, not off the instance.
A stable, addressable registered instance. The sponsor is mandatory and must be a human, so orphan agents cannot exist by construction.
Never persisted as an identity object. The human binding is a claim on the session, not an attribute of the identity — the same instance may run autonomously, or act for different people at different moments.
human (sub) → agent instance (act) → upstream credential — mandatory sponsor, strict subset, never landing on the agent. The word “non-human” must not crowd out the fact that the human is still in the chain — the entire force of the SOC 2 CC6.1 / CC6.6 attribution argument comes from being able to trace back to a person.
idtyp in a token.
Where we sit
The MCP authorization spec already split Resource Server from Authorization Server. We are natively that AS — this is not a wedge, it is the integration point the spec defines.
Human ---- SSO / OIDC ----> Your IdP (Okta / Entra / Google)
| |
| launches | Tu id_token, TTL ~1h (your policy, not ours)
v |
+-----------------------------+ |
| Agent host process | |
| Claude Code / Cursor / | |
| Codex / in-house framework | |
+--------------+--------------+ |
| MCP (stdio | HTTP)
v |
+-----------------------------+ |
| AgentPAM Local Attestor |<-+ V2 . user-space only . heuristic
| process + device signals |
| Secure Enclave device key |
| DPoP per-request signature |
| strips creds from the env |
+--------------+--------------+
v
+-----------------------------+
| YOUR MCP Gateway | Resource Server -- yours. We do not build one.
+--------------+--------------+
| RFC 9728 AS delegation | RFC 8693 token exchange | ext_authz
v
+=========================================================+
| AgentPAM control plane (your Linux, air-gap capable) |
| Identity registry Blueprint / Identity / Session |
| PDP AuthZEN + COAZ, per-tool/param |
| Credential broker RFC 8693 exchange, DPoP-bound |
| Audit spine OCSF + W3C Trace Context |
| CAEP consumer revoke inside one token TTL |
+=============================+===========================+
| Tup 60-300s, header-injected
v *** THE AGENT NEVER SEES THIS ***
+-----------------------------+
| Sensitive API |
| GitHub / Postgres / AWS / |
| Snowflake / internal SaaS |
+-----------------------------+==== box. The IdP is yours, the gateway is yours, the upstream APIs are yours. The Local Attestor is an optional pure-userspace component whose attestation signal is heuristic. see the security modelWrapping an existing product in an MCP server. Security value: zero. We have to say up front that we are not this layer, or we get filed under noise.
Pointing IGA at an agent inventory. Genuinely useful, and it is our V1 wedge — but it counts things; it does not intercept them.
On the request path: verify identity per call, evaluate policy, inject the credential, write the audit record, and be able to say no. This is the only position that can enforce per tool call.
Integration
RFC 9728 requires the gateway to publish authorization_servers, and the spec permits that AS to be external — so on gateways that support pointing it outward, adopting us is a configuration change. To be clear though: the spec does not require that AS to be external, and a gateway may be its own AS, so this path is not universal. Of 12 gateways tested, 4 support it cleanly.
/.well-known/oauth-protected-resource with authorization_servers pointing at your AgentPAM instance.Required by RFC 9728WWW-Authenticate header pointing to it on 401. ⚠️ As of the 2025-11-25 spec (SEP-985) this step is optional — clients may fall back to .well-known discovery.backendAuth.oauthTokenExchange.path at our token endpoint. This is the only genuinely new piece of configuration. (The local YAML key is path; tokenEndpointPath is the xDS/proto field name and will fail to load in a config file.)We implement the AuthZEN / COAZ-MCP PDP interface and register as an external authorizer (gRPC guardrails or Envoy ext_authz), injecting credentials via header mutation on allow. Cost: we see the request but do not own token issuance.
We sit as an upstream MCP server proxied by your gateway, becoming the policy enforcement proxy in front of the real tools. Cost: an extra hop, and we only see traffic routed to us. Benefit: zero requirements on your gateway.
The compatibility matrix and per-gateway test status are on the architecture page — most rows are still marked “not yet tested,” and we will not write an untested row up as verified. See the compatibility matrix →
Enforcement tiers
We do not ship every enforcement layer at once. The practical reason: OS-level enforcement needs kernel extensions, MDM push, and security-team sign-off, and developers will not self-install that — and developers are the first users. The deeper reason: Tier 0 already absorbs most bypass scenarios in principle.
The decisive control point. If the agent holds no credential, going around us and calling curl directly gets it nothing. In principle this absorbs most of Tier 3's value.
The main control surface. Deny by default: any tool call not explicitly permitted by policy is refused, and fail-open is prohibited. Granularity at server level, tool level, and parameter level.
Catches residual credentials and the engineer's pre-existing credentials — ~/.aws/credentials, kubeconfig, the things already on the machine that never go through MCP.
Answers the “non-MCP actions fall outside policy” competitive attack. That is an enterprise-stage problem, not a V1 problem.
Deployment posture
This is not a deployment option, it is a hard constraint. Credential custody means this control plane holds the keys to all of your sensitive APIs — those keys should not leave your network boundary.
The control plane runs in your own Linux environment and requires no outbound cloud access. Any feature that would only work via our SaaS does not get built.
OCI images + Compose / Helm. Minimal base image, runs non-root, read-only root filesystem, explicit capability set and network policy — because your security team will audit the image.
No telemetry, no online licence checks, no auto-update callbacks. Licences are offline signed files; updates are images you pull deliberately. Any “calling home” behaviour is an incident at an air-gapped customer.
One structural consequence is worth saying plainly: any approach that presupposes a public-cloud bundle simply does not exist as an option in an air-gapped environment. That is not a claim about who is better; it follows from the deployment shape.
What ships
Customer-side endpoints open source, control plane commercial. Discovery and attribution first, enforcement second — because nobody buys enforcement for a population they cannot count.
Read-only CLI / lightweight daemon. One docker run, connected to nothing, producing: how many agents exist, what credentials each holds, what they touched last week, and which are unattributable under SOC 2 CC6. Zero blast radius.
An OCI container group deployed on your own Linux — not SaaS. Identity registry, policy editing, audit views, auditor-ready reports, and approval-fatigue metrics — an approval rate approaching 100% is a rubber-stamp signal.
A service inside the same container group. Per-call policy decisions and RFC 8693 token exchange; credentials are held here and injected per request. Target P99 latency < 200ms.
A code-signed daemon. It cannot be an SDK — an SDK runs inside the process being attested, so it would be attesting itself, which is logically void; and the credential has to be held outside the agent process.
Boundaries
This section is here because it is more useful to you than to us. If we were vague about any line below, your team would catch it in the second meeting.