From agent identity to a decision on every call
I have been writing about a problem that keeps showing up in agent deployments: software acts through a human session, carries that person’s credentials and leaves a record that attributes the action to the person. When something goes wrong, the account name tells us too little.
My earlier articles examined the identity gap, what changed as protocols developed and the parts of an identity stack that teams still have to connect. On October 27, NIST published ten design tenets for agent identity management systems. They give that discussion a practical structure.
I build Oktsec, a security gateway for AI agents. I read the tenets with one question: what has to be true when an agent tries to call a tool?
These are proposed design principles from the NCCoE’s identity and authorization work. NIST says organizations should apply them according to transaction risk, deployment environment and the resources agents can reach.
The ten tenets, read as runtime checks
The names below are NIST’s. The checks are my interpretation of what an implementation team should be able to demonstrate.
| NIST tenet | A concrete implementation check |
|---|---|
| TENET 01Distinct Agent Identification | Distinguish this agent from its operator and other agents. Verify its identity and the lifecycle of the credential it presents. |
| TENET 02Agent Linking, Delegation & Attenuation | Trace authority to the task originator. Reject a delegation that widens the scope received by its parent. |
| TENET 03Least & Zero Standing Privilege | Check that an idle agent has no persistent authority and that task permissions exclude unrelated actions. |
| TENET 04Short-Lived, Dynamic & Revocable Authorization | Check the audience, expiry and current authorization on each call. Verify that revocation stops subsequent access. |
| TENET 05Human-in-the-Loop Triggers | Hold a sensitive action before execution, route it to the correct approver and supply enough evidence for a decision. |
| TENET 06Mandates and Constraints | Verify the originator’s signed task outcome and limits downstream. Do not substitute an unsigned prompt for this record. |
| TENET 07Architectural Separation of Policy from Reasoning | Confirm that model output cannot change the permissions, credentials or enforcement mechanism that govern its tools. |
| TENET 08Deterministic Access Decisions | Reproduce a decision from the request, policy version and relevant state. Keep probabilistic assessments as inputs. |
| TENET 09Continuous Monitoring | Detect changes in access, configuration and behavior with metrics and thresholds appropriate to agents. |
| TENET 10Immutable Evidence | Preserve identity, delegated intent and actions in an independent, append-only record with verifiable integrity. |
These controls depend on each other. A valid agent identity does not stop a confused deputy from misusing legitimate access. Delegation, limited permissions and an external policy decision have to hold together. NIST also acknowledges that current standards and technologies do not yet fulfill every tenet across all deployment models.
Three tenets that change the architecture
Separate policy from reasoning
A model receives instructions and untrusted material through the same token interface. A document, tool response or repository file can therefore influence what it attempts. The enforcement point must remain outside that reasoning process.
For an MCP workflow, I would test this at the gateway: permit a research agent to read an approved directory, then request a different path, a disallowed tool and an outbound destination outside its scope. Each must be evaluated before the backend executes the action. A warning in the conversation is not evidence that execution was prevented.
This boundary also depends on deployment. If the agent can edit the gateway’s policy, read its signing keys or call the backend directly with the same credentials, the separate process alone has not established separation. Network paths, filesystem permissions and credential custody belong in the test.
Make the access decision deterministic
NIST permits probabilistic information as input. A classifier can identify suspicious content or a model can help an analyst assess a case. The permission decision still needs defined rules.
Determinism means the same request, policy and relevant state produce the same result. A request can correctly change from allowed to denied after a credential expires, a rate limit is reached or an administrator suspends the agent. To replay that decision, retain the policy version and the state that mattered.
In a deployment test, revoke a disposable identity during an active task. Check the next attempted call, the backend’s execution record and the policy log together. This verifies containment during execution rather than authentication at session start.
Keep evidence outside the agent’s control
Hash chains and signatures make modifications detectable when a verifier has trusted keys and a trustworthy reference point. They do not, by themselves, prevent deletion of the database or prove that every action was captured.
For NIST’s evidence tenet, also establish independent storage, restricted writers, retention and continuity checks. Export a signed checkpoint to a separate administrative boundary. Verify it without giving the agent access to the signing key or the evidence store. Record gaps explicitly: a valid signature on an incomplete export does not make the history complete.
Delegation and mandates are different controls
Delegation answers whose authority an agent carries and how far that authority extends. A mandate adds what the originator intended to accomplish and the constraints on that task. A general permission to use a payment API does not express an instruction to reimburse a particular invoice up to a specified amount.
NIST’s August identity post points to existing IAM building blocks and ongoing standards work. Transaction Tokens address authorization context across service calls. The Identity Assertion JWT Authorization Grant describes obtaining API access through identity providers and authorization servers that share trust. These are Internet-Drafts; their existence does not establish deployment or interoperability in a customer environment.
Rich Authorization Requests, RFC 9396, provides an authorization_details parameter for fine-grained authorization data. It is a useful building block, not proof that a system verifies a signed mandate throughout an agent task.
The practical exercise is to follow one delegated request through every hop. Record the originator, delegate, recipient, tools, expiry and effective permissions. Attempt to widen scope at the next hop and check that the relying service rejects it. Then separately test whether the intended business outcome and its limits survive the handoff.
Credentials expire; review needs an owner
A static API key is a convenient shortcut during a prototype. It becomes a persistent access path when copied into agent configurations, environment variables or logs. Removing it from the prompt does not remove that access from the process.
Use short-lived grants for the intended audience and test revocation against the actual resource server. DPoP, RFC 9449, constrains OAuth tokens to a client key and helps detect token replay. It does not protect against an attacker who can use the authorized client and its key. Key custody remains part of the design.
NIST IR 8587 covers token and assertion protection, verification and lifecycle controls. The August blog referred to its draft; the final report was published in September 2026.
Human review needs similar operational detail. Define which actions must pause, who may approve them and what happens when approval expires or nobody responds. A flag that allows execution is monitoring, not a pre-execution approval gate. Measure repeated prompts and habitual approvals: an overloaded review queue can undermine an otherwise sound policy.
Where Oktsec stands
This is our implementation mapping as of October 30, 2026. It describes available controls and the remaining integration work. It does not establish that every deployment meets the full tenet. In particular, a gateway cannot supply zero standing privilege if the agent retains broad credentials or a direct route to the backend.
| Tenet | Oktsec capability | Remaining requirement |
|---|---|---|
| TENET 01Identification | Per-agent Ed25519 identities, key management and inventory. | Bind identity to the intended workload and approved configuration. Inventory is not hardware attestation. |
| TENET 02Delegation | Signed delegation verification supports expiry, parent linkage, depth and recipient scope on the HTTP messaging path. | Enforce MCP tool access through configured allowlists. Delegated tool-scope inspection is not a pre-execution gate; validate scope enforcement at each downstream service. |
| TENET 03Least privilege | Configured tool allowlists and pattern/length constraints on top-level string arguments. | Validate missing, nested and non-string arguments separately. Issue temporary downstream credentials and remove bypass paths and idle authority. |
| TENET 04Revocable authorization | Configured agent suspension and policy blocking stop subsequent mediated calls. | Verify downstream revocation and existing sessions. Suspension does not cancel calls already executing or revoke external credentials. |
| TENET 05Human review | A quarantine verdict prevents the MCP backend call; flagging records findings while permitting delivery. | Verify review-queue persistence, approver routing and expiry. Approval changes review state; it does not establish automatic replay or resumption. |
| TENET 06Mandates | Signed organizational policy bundles provide an administrative policy mechanism. | A policy bundle is not a per-task mandate signed by the task originator. That complete flow is not claimed here. |
| TENET 07Separation | A gateway outside the model’s reasoning process enforces access. | Protect its process, keys and configuration from the agent. Ensure all relevant backend access crosses it. |
| TENET 08Deterministic decisions | Identity, permissions, constraints and content rules produce defined enforcement outcomes. | Retain policy and relevant state for replay. Validate failure behavior for the selected deployment profile. |
| TENET 09Monitoring | Audit events, risk signals and inventory records provide visibility into mediated activity. | Set thresholds, verify collection coverage and assign owners for alerts and configuration changes. Monitoring a gateway does not observe every host action. |
| TENET 10Evidence | Hash-chained audit records and cryptographic verification support integrity checks. | Independent retention, trusted checkpoints and protected signing keys are needed. Tamper evidence alone does not prevent deletion. |
What a team can check this quarter
- Inventory agents and access paths. Include coding assistants on developer machines, their MCP servers, credentials and direct network access.
- Trace one consequential tool call. Identify the agent, originator, delegated scope, policy version, enforcement decision and backend outcome.
- Exercise the denied paths. Test an expired grant, a revoked identity, a widened delegation and an unapproved destination in an authorized test environment.
- Test approval before execution. Confirm that a sensitive action stays pending until the correct person approves it, and that an expired approval cannot be reused.
- Verify evidence independently. Check a retained export from another administrative boundary and establish how missing records or deleted history would be detected.
NIST’s tenets give teams a useful set of questions. Answer them with an actual request, a policy decision and an execution record. That is where the design becomes testable.
Disclosure: I am the founder of Oktsec. The product mapping is our own assessment, not an endorsement or evaluation by NIST. Sources and implementation statements were reviewed on October 30, 2026.
References
- NIST: Design Tenets for Agent Identity Management Systems · October 27, 2026.
- NIST: Why Agentic AI Needs a Strong Identity Foundation · August 27, 2026.
- NCCoE agent identity and authorization project.
- NIST IR 8587: Protecting Tokens and Assertions from Forgery, Theft, and Misuse · final report, September 2026.
- RFC 9449: OAuth 2.0 Demonstrating Proof of Possession and RFC 9396: Rich Authorization Requests.
- OAuth Transaction Tokens and Identity Assertion JWT Authorization Grant · Internet-Drafts.