2938 Members
Join Permit's SlackCall it the "verified-agent, unverified-action" tension: your platform can now verify that an AI agent is real, signed, and enterprise-governed, yet still cannot reliably decide whether that agent should execute this MCP tool call against that production resource in this session.
That tension is no longer hypothetical. The IETF work on SD-JWT-based agent credentials gives the ecosystem a standards path for cryptographically verifiable agent claims and selective disclosure in discovery flows, including the emerging agent profile draft (IETF draft-nandakumar-agent-sd-jwt). At the same time, Microsoft Entra Agent ID is designed to enhance identity management with features like agent identity verification and lifecycle management, and a growing set of enterprise governance scaffolding covered in the Entra Agent ID governance guide. Together, these are an inflection point.
But they also expose the gap: identity answers who an agent is; authorization must still answer what it may do right now. If your architecture treats these as the same problem, you end up with the security equivalent of giving everyone with a valid company badge access to every room in the building — as long as the badge scans. Convenient, until it's catastrophic.
The industry has used machine identity for years: certificates for workloads, OAuth clients for apps, service accounts for automation, SPIFFE IDs for services, API keys for headless scripts. These mechanisms are necessary and mature, but they were designed around software entities that execute predefined tasks, not semi-autonomous systems reasoning over dynamic goals.
That is why agent identity vs machine identity is not a semantic debate. It is a control-plane distinction.
A classic machine identity says:
payments-batch-prod."crm-sync-client."An agent identity (or agentic identity) must say more:
vendor-risk-copilot."sarah@company.com."evaluate vendor onboarding packet."A useful definitional anchor for architecture reviews is this: agentic identity = delegating human + workflow context + intent + agent credential. If you remove delegator, context, and intent, you regress to machine identity with a fancier label. That is exactly how teams accidentally recreate overprivileged service-account patterns under a new AI brand.
Service accounts still matter. They are often part of an agent's execution substrate. But a service account is best thought of as transport identity: it proves code instance authenticity to infrastructure. Agent identity is decision identity: it carries enough semantics for policy to evaluate delegation, scope, and behavioral boundaries.
There is also a lifecycle mismatch. Service accounts are often long-lived and environment-bound. Agents are frequently session-oriented, intent-scoped, and potentially re-composed through sub-agent delegation. In other words, machine identity is usually static and infrastructural; agent identity is dynamic and interactional.
A wry but accurate observation: many "AI security" roadmaps are just legacy IAM with better slide design. They verify signatures impeccably and then authorize with a coarse role like agent:trusted. That works right up until an agent with a valid identity decides that "retrieve customer status" might include exporting 200,000 records "for analysis."
As agent ecosystems move toward interoperable discovery, A2A Agent Card-style metadata becomes critical. Think of an Agent Card as a structured profile: capabilities, issuer claims, supported protocols, and other verifiable attributes that another system can consume before deciding to interact.
The interesting part is when Agent Cards are represented with SD-JWT patterns. SD-JWT (Selective Disclosure JWT) allows an issuer to sign claims while enabling a holder to reveal only the claims needed for a given interaction. In plain terms: the verifier can trust disclosed attributes without receiving the full identity dossier. This is core to privacy-preserving interoperability and is central to the IETF agent identity discussion (draft-nandakumar-agent-sd-jwt).
For agent-to-agent discovery and handshakes, this gives you powerful mechanics:
The second essential piece is key binding. Without key binding, a disclosed claim set can be replayed by an impostor that intercepted the artifact. With key binding, the presentation is cryptographically tied to a holder key, and the verifier can require proof-of-possession so claims are not separable from the actor presenting them. In agent terms: not only is the card valid, but this specific presenter controls the bound key.
This matters even more in multi-hop agentic systems. If agent A delegates to sub-agent B, and B calls tool C, each hop must preserve verifiability of who is presenting what claims under which key material. Otherwise, delegation collapses into "trust me, a valid token existed somewhere."
However, even perfect SD-JWT hygiene still does not answer runtime questions like: Is this action allowed for this human delegator? Is this intent still within approved scope? Has session risk changed since initial discovery? Is this tool call safe against current data sensitivity policy? Agent Cards are best treated as identity and capability evidence, not as standalone execution permission.
Where standards define interoperable identity artifacts, enterprise programs need governance mechanics. That is where Microsoft Entra Agent ID is notable: it frames agents as governable principals with explicit enterprise lifecycle structures rather than ad hoc bot accounts (Entra Agent ID governance guide).
From a platform architecture perspective, several concepts stand out.
Agent blueprints give teams repeatable patterns for how an agent is instantiated, constrained, and connected. This helps avoid "snowflake agents" where each team invents identity behavior differently.
Agent sponsor relationships create accountable ownership. If no human sponsor is answerable for an agent's risk posture, your controls degrade into policy theater. Entra makes this explicit: every governed agent has an identifiable human or team responsible for its behavior and lifecycle.
Access packages align agent permissions with governed bundles instead of one-off grants. This is important in organizations where compliance depends on reviewable entitlements and periodic recertification.
Conditional access principles can extend to agent sessions, adding context checks such as environment trust, network posture, or additional constraints before sensitive operations proceed.
Logs and governance telemetry improve traceability: who created the agent, under which governance path, with what assignments, and how controls changed over time.
This is substantial progress. It operationalizes agent sponsor accountability and lifecycle governance that most organizations lacked entirely. But be careful not to over-interpret what these controls do. Governance layers are excellent at baseline trust and enrollment standards. They do not automatically express a fine-grained decision such as: "Agent X, delegated by analyst Y, inside incident Z, may invoke MCP tool runQuery on dataset D only with column masking and a row-limit threshold under risk profile R." That decision requires runtime semantics many directory-centric systems were never meant to adjudicate alone. You need governance and runtime, not governance instead of runtime.
Here is the practical line in the sand: identity systems establish principal authenticity and baseline trust; runtime authorization decides whether a requested action is permitted under current conditions.
For MCP and similar tool ecosystems, identity alone cannot answer five dimensions that determine safe execution.
FOR WHOM — An agent may carry a valid credential, but authorization must evaluate the human delegator and delegation legitimacy. The same agent behavior might be allowed for a senior fraud investigator and disallowed for a temporary contractor.
WHY — You need policy over intent, not just actor. "Summarize account anomalies" and "bulk export account records" are different intents even if the same tool endpoint could perform both.
IN WHAT CONTEXT — Context includes session metadata, tenant boundary, resource classification, environment, time, and interaction channel. Authorization must be context-sensitive because risk is not static.
WHAT RISK LEVEL — A low-risk read in a sandbox is not equivalent to a high-risk write in production. Runtime controls should adapt to risk scoring, anomaly signals, and data sensitivity.
WHAT DELEGATION CHAIN — In agentic systems, actions often occur through agentic delegation and sub-agent calls. Authorization must reason over the chain: delegator → primary agent → sub-agent → tool call. Broken chain visibility means broken accountability.
If this sounds like overengineering, consider the alternative: you're effectively implementing "all authenticated agents are trusted for all declared capabilities." That is not zero trust; that is zero imagination.
The badge analogy makes this concrete. A signed Agent Card is a tamper-resistant employee badge: it proves identity and some attributes. Runtime authorization is the door controller checking whether this badge holder can enter this lab at this time for this purpose with this escort policy. Nobody serious confuses the badge printer with the door policy engine. Yet teams routinely do exactly that in AI stacks.
A workable MCP authorization design starts with a canonical context tuple captured at every tool invocation.
You can model each decision as:
(human_delegator, agent_identity, intent, trust_level, tool, resource, context, policy_version, delegation_chain) → allow | deny | allow_with_obligations
This is the operational expression of the enterprise model: human delegator + agent identity + intent + trust level + tool + resource + context + policy + audit. Each element should be explicit:
Then define decision outputs beyond binary allow/deny. allow when all policy predicates pass. deny when any hard constraint fails. allow_with_obligations when execution is permitted only with enforced conditions: mask PII, redact fields, limit rows, require user step-up confirmation, force read-only mode, capture extra audit. For tool-call authorization, obligations are often the difference between usable and safe — they let business workflows proceed while applying compensating controls rather than bluntly blocking everything uncertain.
Implementation guidance for engineering teams: normalize intents into a controlled vocabulary (free-text prompts are poor policy keys), require delegation tokens to be short-lived and session-bound, propagate delegation chain metadata across every internal call boundary, evaluate policy at invocation time not only at session start, and log full decision context and rationale for replayable audits. Add explicit deny rules for high-risk tool/resource combinations by default.
This is where a dedicated runtime authorization layer belongs. Identity providers, credential standards, and governance systems establish trustworthy principals and baseline controls. A policy decision point must still evaluate live MCP invocations against the full context tuple.
That is precisely the role of Permit.io: centralized, policy-driven authorization that can evaluate rich context in real time and return deterministic decisions your tool gateway can enforce. The design center is not "who exists" but "who can do what, now, and under which conditions."
In an agentic architecture, that typically looks like: the agent/session arrives with identity evidence (including agent credential claims); the application resolves delegator, intent, tool, resource, context, and delegation chain; the runtime calls the Permit PDP with this assembled authorization input; the PDP returns an allow/deny/conditional decision; the MCP gateway or tool adapter enforces outcome and obligations; and the audit trail stores the decision payload, policy version, and correlation IDs.
The immediate advantage is policy composability across teams. Instead of hardcoding fragile "if agent X then allow Y" logic inside every tool adapter, you externalize policy and version it. Changes can be reviewed, tested, and rolled out consistently. For teams operating regulated workloads, this is the difference between explainable control and chaotic permission drift.
A minimal policy pattern for agents often includes: delegator-to-agent binding constraints, intent-to-tool compatibility checks, resource sensitivity gates, risk-adaptive conditions (step-up requirements, environment limits), delegation depth limits for sub-agent chains, and mandatory audit obligations for sensitive actions.
If you are implementing this stack, the Permit.io documentation is where to map policy models, PDP/PIP integration patterns, and enforcement points into your MCP topology. The key is architectural separation: let identity systems authenticate principals; let runtime authorization decide and enforce actions. You can embrace interoperable agent identity, support governed enterprise onboarding, and still preserve least privilege at execution time. That is how you make agentic systems both useful and survivable in production.
A service account usually represents a workload and carries broad, relatively static permissions. Agent identity must additionally encode delegation semantics, intent-scoped behavior, and interaction context because agents act on behalf of humans in changing workflows. In other words, service accounts identify software components, while agent identity supports accountable decision-making for agentic actions. The practical test is simple: if you cannot trace an action back to a specific human delegator and a declared intent, you have machine identity, not agent identity.
SD-JWT allows an issuer to sign claims in a way that enables the holder to selectively disclose only the necessary claims for a specific interaction. This supports privacy-preserving discovery because an agent can prove relevant capabilities without disclosing full internal metadata to every orchestrator or registry it interacts with. Combined with key binding, verifiers can trust that disclosed claims are both authentic and presented by the legitimate holder, preventing replay attacks where a stolen Agent Card is reused by an unauthorized actor.
Entra-style governance is excellent for onboarding, ownership, lifecycle, and baseline access posture. MCP tool-call authorization is a per-invocation decision that depends on session context, intent, resource sensitivity, and delegation chain details that change in real time. Governance establishes trust foundations and accountability structures, but runtime policy evaluation determines whether a specific action is permissible right now. These are complementary layers, not alternatives to each other.
At minimum, include human delegator, agent identity, normalized intent, trust level, tool operation, target resource, session context, policy version, and delegation chain. This yields decisions that are explainable and auditable rather than opaque. It also enables conditional enforcement such as masking, row limits, or step-up confirmation when risk is elevated, which is often more practical than a binary block for ambiguous cases.
Sub-agent delegation introduces additional hops where authority can expand, drift, or become ambiguous if not explicitly constrained. Security controls must preserve and validate the full chain of delegation across each hop, not just validate the first caller. Policies should limit delegation depth, scope inherited permissions, and require signed delegation context for sensitive operations so that an orchestrator spawning a sub-agent cannot quietly amplify its own privileges through the child.
Start by inserting a policy decision point at a single choke point — usually an MCP gateway or tool broker — then progressively externalize hardcoded checks. Standardize the decision tuple and require each tool adapter to pass mandatory context fields. This incremental pattern delivers control quickly while allowing teams to mature policy models over time without a big-bang rewrite of existing integrations.
The IETF SD Agent draft defines the credential and presentation layer: how agent claims are structured, signed, selectively disclosed, and key-bound for interoperable discovery. Enterprise governance systems like Entra Agent ID define the management layer: how agents are enrolled, sponsored, lifecycle-managed, and policy-scoped inside an organization. Neither layer includes per-invocation tool-call authorization — that is a third, distinct runtime authorization layer that must evaluate the full context tuple at each MCP call.
Co-Founder / CEO at Permit.io
