For approximately twelve months, the corpus argument from this publication has been that the access model behind the MCP abstraction is the binding constraint on enterprise agentic deployments. The MCP interface is the right seam. Standardized auth, discovery, and audit hooks are necessary primitives. None of them is sufficient. A standard interface in front of an over-privileged service account is, in operational terms, no improvement over no interface at all. The blast radius is unchanged. The differentiation between agent-initiated and human-initiated calls cannot be enforced. The session bound that would limit the time and authority dimension of any single invocation does not exist.
The Oasis AAM page articulates a chain of custody for runtime authorization that maps directly onto the architectural argument: Prompt → Intent → Policy → Session → Action. Read in sequence, the chain names what the deployment layer has been missing. The prompt is the originating user intent. The intent is the agent’s decomposition of that prompt into an action plan. The policy is the organizational rule set that the action plan is checked against. The session is the ephemeral, time-bound, scope-limited identity that gets provisioned for the specific action. The action is what actually reaches the resource — and the chain is what makes the action accountable.
The Category Names a Real Gap
What AAM contributes — and what makes the category emergence significant — is the integration of three primitives that have, until now, been deployed separately. Session-level provisioning with ephemeral identities replaces standing privilege. Time-bound, policy-driven escalation handles the cases where elevated authority is genuinely needed but cannot be left ambient. Identity-to-prompt mapping makes the chain of custody auditable end-to-end. Each of these primitives has existed somewhere in enterprise security. The category framing matters because it integrates them around the agentic use case rather than retrofitting them from non-human identity (NHI) management or privileged access management (PAM) frameworks designed for non-agentic systems.
Stages in the AAM chain of custody — Prompt → Intent → Policy → Session → Action. Each stage carries metadata that the next stage validates. Each transition is a potential enforcement point. The architecture matters because the absence of any stage in the chain is what creates the gap that current MCP deployments leave open.
The category framing is not the same as solving the problem. AAM is a deployment-layer remediation. It operates above the protocol — below the agent framework — at the runtime authorization plane. Three boundary lines define where the work lives, where it stops, and where the next round begins. Each one is productive rather than reductive: each names a layer the category does not own, and each names a problem the architectural argument has been pointing at for some time.
Boundary One: Probabilistic Input, Deterministic Enforcement
The first boundary line is the cleanest, and the most useful for the practitioner. AAM correctly pairs probabilistic and deterministic mechanisms — but the pairing has to be understood for what it is. The intent analysis stage is probabilistic. Decomposing a prompt into an action plan and determining the access required for that plan is the kind of task that LLMs are now competent at, but competence is not the same as enforceability. Intent classification is a necessary input to the access decision. It is not the access decision itself.
The session policies, ephemeral identities, and policy-bound expiration are deterministic. They are structural and enforceable: the session either exists with the scope it was provisioned with, or it does not exist at all. The expiration either fires, or the session is invalid. The policy engine either approves the action against the rule set, or the action does not execute. These mechanisms work in the same way regardless of whether the intent classifier read the prompt correctly.
What the Intent Classifier Provides
The intent analysis stage decomposes a prompt into a structured action plan and a scoped access request. This is where the agent’s understanding of the user’s goal is encoded into something the deterministic layers can check. The classifier is necessary because the prompt itself is unstructured natural language, and the policy engine cannot evaluate against unstructured input.
Like every probabilistic input to an enforcement decision, the classifier can be wrong. The right architectural move is the same one that holds across the corpus: treat the classifier as input, not as the gate. Pair it with structural scoping that holds even when the classifier reads the prompt incorrectly.
Necessary · Not SufficientWhat Session Provisioning Provides
The ephemeral identity exists with the exact scope it was provisioned with — no more, no less. The session policy attached to it cannot be expanded by the agent at runtime. The expiration is a hard boundary; once the time window closes, the session is dead and any subsequent action requires a new authorization cycle that returns to the policy engine.
This is what makes AAM more than an intent layer. The probabilistic component cannot widen the deterministic boundary. If the classifier mis-reads the prompt, the worst case is a wasted session — not an unbounded action surface. That is the correct architectural posture for a system that mixes probabilistic and deterministic components.
Structural · EnforceableThe corpus has carried this distinction since Series 1. Probabilistic controls are necessary but not sufficient. Deterministic controls are structural and enforceable. AAM pairs both correctly. The boundary line that matters is between them: the architecture works because the probabilistic component cannot widen the deterministic boundary, regardless of what the classifier infers.
Boundary Two: The Two Paths and the Identity Layer
The second boundary line is one that AWS named at the IAM layer in the same week. Riggs Goodman III, in the AWS Security Blog post on securing AI agent access through MCP, articulated the same scope-of-impact reframe that the corpus has been making at the protocol layer: design permissions for the acceptable scope of impact, not for the intended functionality. The third principle in the AWS guidance — differentiate AI-driven from human-initiated actions — relies on context keys and session tags that only fire when the agent reaches AWS through an MCP server. The bash path bypasses that specific mechanism.
Two Paths, Two Governance Layers
An agent has two paths to enterprise resources: the MCP path, where calls flow through the MCP server and AAM enforcement plane; and the non-MCP path, where the agent invokes a shell tool, calls a CLI, or hits an API directly through underlying credentials. Both paths need governance — but they are governed by different mechanisms in the same identity stack. The MCP path is governed by AAM: chain of custody, session-bound scope, in-session tool and action enforcement, fine-grained authorization. The non-MCP path is governed by Non-Human Identity Management: discovery and inventory of every service account, API key, and IAM role the agent could exercise; ownership and lifecycle controls; vault-mediated access; rotation and decommissioning. Together, NHIM and AAM close the agent’s paths to action — neither alone does.
This is the architectural read that strengthens the corpus argument rather than weakening it. The bash path is not an unmanaged escape route — it is the path NHIM was built to govern. AAM was built to govern the MCP path. The two together make the agent’s action surface fully accountable, and that is exactly why the Oasis NHI pedigree matters for AAM in a way that a pure-play AAM entrant could not replicate. Two products, two paths, one identity stack.
AAM itself does more than session provisioning. Within the chain of custody, AAM enforces tool-scope and fine-grained authorization at the action stage — not just at the session boundary. The action either matches the policy and the session’s permitted scope, or it does not execute. The narrower upstream point that remains: what tools exist for the agent at all is decided at the agent framework layer (Bedrock AgentCore allowlists, Copilot tool surfaces, custom agent toolbelts). That is upstream of the AAM/NHIM split — the layer that decides which paths the agent has access to in the first place. Once the agent has those paths, AAM and NHIM govern what it can do with them.
Boundary Three: The Session Bound and the Agentic State Problem
The third boundary line is where the corpus has been pointing for the longest time, and where the deepest open work lives. AAM’s session is a powerful primitive: it bounds the time during which an authorization is valid, and it bounds the authority granted within that time. Both bounds are deterministic and enforceable. But agents do not operate purely in session-bounded space. The session is one dimension of the larger agentic state — the dimension that AAM addresses well, and the dimensions it does not address are precisely where Series 5 of this publication named the agentic state problem.
What the Session Bounds — and What It Does Not
The session bounds time (the window during which the credential is valid) and authority (the scope of access the credential permits). Both are concrete, both are enforceable, and both are what makes AAM work as a runtime authorization mechanism.
The session does not bound memory — what the agent has retained across sessions about prior conversations, prior tool outputs, prior reasoning. The session does not bound conversation history — the accumulating context that shapes the agent’s interpretation of new prompts. The session does not bound tool composition — the way the agent chains multiple tools together within a session, where each individual tool call is in scope but the composition produces an effect outside the policy author’s intent.
Series 5 Post 1 named this directly: agentic systems do not have linear authorization histories the way traditional systems do. A user authorization is granted at one moment, but the agent acts on that authorization across an unfolding context that includes memory, conversation history, and dynamic tool composition. The chain of custody AAM provides — Prompt → Intent → Policy → Session → Action — is a clean linear history for a single invocation. The agentic state problem is what happens when the agent’s behavior across many invocations produces effects that none of the individual invocations were authorized for.
This is not a gap in AAM. This is a generative direction for the category. Session-level chain of custody is the precondition for solving the cross-session state problem. You cannot reason about cross-session effects until you have a clean per-session history to reason from. AAM provides the per-session primitive. The next round of work — likely in the form of session-spanning policy engines that can evaluate cumulative authorization rather than per-action authorization — is what closes the cross-session gap.
The category is doing real work. The boundary lines are where the next round of work has to happen — alongside NHIM at the identity layer, at the cross-session policy layer, and at the protocol layer underneath on a different timescale. None of these is a deficiency. All of them are the correct architectural read of what one layer can and cannot deliver on its own.
— Luminity Digital synthesis on the AAM category emergence, April 2026What This Says About Deployment-Layer Remediation
The empirical-research argument that preceded this dispatch made the case that remediation has three viable layers: protocol, SDK, and deployment. AAM is the first coherent product surface that operates at the deployment layer with full intent. It is the existence proof for the corollary the corpus has been making for some time: enterprise architects do not have to wait on the MCP protocol to evolve before they can ship runtime authorization that is structurally meaningful.
The protocol layer still has to evolve. Cryptographic agent identity, verifiable delegation chains, and structural separation of command and data at the inference layer are all problems that the deployment layer cannot solve. They are the work of the next several years. The deployment layer buys time for that work to mature, and it reduces blast radius now in ways that matter operationally — but it does not eliminate the case for the protocol-layer work to happen.
What changes with the AAM category is that the enterprise practitioner now has a concrete answer to the question that has been hanging over MCP adoption: what do we do in the meantime? The answer is no longer “wait.” It is: deploy AAM and NHIM together to govern both the MCP path and the non-MCP path of every agent in the environment, address the cross-session policy gap on a longer timeline, and continue to push for protocol-layer evolution. The three layers move on different clocks. None of them substitutes for the others. All of them are necessary.
The architectural argument that protocol-level failures cannot be governance-resolved was always going to require deployment-layer existence proofs to land. AAM as a named category is one of those existence proofs. The work that remains is alongside NHIM at the identity layer (governing the non-MCP paths the agent can also exercise), at the cross-session policy layer (the agentic state problem), and at the protocol layer below (cryptographic identity, verifiable delegation). The deployment layer does not wait — and it does not finish the job. Both halves of that statement are what the practitioner needs to hold.
