Identity and authorization are separate checks. A signed workload identity can tell the resource server who is calling; it cannot by itself establish that a particular principal delegated a write on a particular table. A robust architecture represents both identities and the right exercised in each operation. This distinction becomes critical with ephemeral instances, multi-tenant tools and subagents.
Represent grants as action tuples. A practical tuple contains principal, authenticated agent, task, target tenant/object, operation, authorized tool, context predicates, validity period, parent delegation reference, approval constraint, revocation state and audit linkage. The Ariftly Agent Authority Matrix provides these as twelve dimensions. It is a conceptual schema to adapt, not a normative wire protocol. Implementation teams must map each dimension into token claims, authorization server data, policy engine attributes, workflow metadata or evidence stores according to architecture and data minimization needs.
Start with mature protocol building blocks. SPIFFE supports cryptographically verifiable workload identity. RFC 8693 defines OAuth token exchange including delegation and impersonation semantics. RFC 9396 permits more expressive authorization details. RFC 9068 describes a JWT access-token profile; RFC 9449 supports sender-constrained tokens using DPoP; RFC 9700 provides updated OAuth security practice. None supplies a ready-made universal agent governance product. Deployments must verify token issuers and audiences, ensure resource-server checks, manage key rotation and define how current revocation state is enforced. Agent-specific Internet-Drafts need status/date checks; drafts must never be described as mature RFCs.
Narrow every delegation. Construct a parent–child grant graph and prohibit child authorizations outside parent policy scope. Store the parent grant ID and a deterministic comparison result. A tool invocation should not turn a request like “help complete validation” into an unrestricted inheritance of the operator's identity. If a workflow genuinely needs elevated access, route that escalation through a separately authorized grant with an accountable owner and expiry.
Do not confuse intent with permission. A model can infer useful steps from a task, including steps outside the authorized scope. It may be correct about the technical utility of a command and wrong about entitlement to execute it. The enforcement layer should parse the actual requested operation and target resource, evaluate trusted attributes and block operations whose permissions cannot be proven. Model-written arguments and retrieved text are inputs, not policy instructions. Deterministic enforcement should be outside the model's control.
Make approvals specific. Human sign-off must correspond to a defined transaction. Capture a digest or normalized representation of the action, resource, constraints, expected effect, expiry and approver identity. A model should not be able to materially change those parameters and reuse the old approval. Approval UI should present intelligible impact and avoid indiscriminate prompting for routine, low-risk steps; NIST's stakeholder synthesis raises consent-fatigue concerns.
Test revocation. Expiry and revocation answer different questions. Short validity limits how long a credential can survive but does not automatically stop an already accepted token or an in-flight tool call. Define what must happen after an owner cancels authority: new calls denied, queued actions blocked, downstream grants invalidated or bounded by their own expiry, and consequential partial execution escalated. Measure actual propagation times in the organization's specific environment and report the measurement method if making a latency claim.
Make audit evidence reconstructable and privacy-aware. The minimal useful chain contains a request ID, identity and principal references, task, grant, policy version, decision reason, approval reference, tool execution ID, validation result and exception disposition. Do not dump arbitrary conversations, sensitive records or long-lived secrets into an audit lake simply to improve observability. Use hashes or controlled references where appropriate, enforce access restrictions and explicit retention periods.
Demonstrate denials, not only happy paths. Create test cases for nonexistent agent identity, forbidden tenant, denied action, expanded subagent scope, stale grant, changed approval, revoked credential and malicious instructions embedded in tool output. Require both a correct enforcement result and an evidence record. A design inventory can show completeness, but only reproducible enforcement testing—and eventually independent production evidence—can inform operational assurance.
Quantitative honesty matters. NIST reports more than 600 responses to its February 2026 concept paper. It does not claim the number represents security incidents or share of enterprises. Similarly, a fictional authority record with nine verified design fields out of twelve yields 75% completeness, not a statement that the workflow is 75% secure. Any security outcome percentage needs a clearly defined population, threat model, repeatable test, environment and denominator.
Workflow ownership remains human. For an AI-assisted workflow, the person may take action after the model prepares the inputs. Bounded execution permits an agent to perform a few well-validated operations without expanding its authority. More autonomous execution requires evidence of reliability and accountable review for exceptions, rather than a role name that implies unlimited permission. This is the separation between autonomy level and action authority.
For AI-Native Modernization, a hypothetical Oracle-to-Snowflake analysis might allow an assessment agent to read synthetic SQL, then a specialized validation agent to run read-only checks. It should not permit production writes by implication. Ariftly's Forge experience is in development; the example is a design pattern, not a reported product feature or customer result.
A strong review meeting ends with a verifiable question: can the team point to the exact grant, enforced decision and validated outcome for one selected action? If not, reduce the scope or return the action to a responsible human until the chain is testable.
Originally published by Ariftly with the full source ledger, twelve-field matrix, synthetic fixtures, and downloadable schema: https://www.ariftly.io/insights/ai-agent-identity-authorization-least-privilege
Disclosure: This article presents an Ariftly-authored engineering framework. The example is synthetic, the matrix is not a NIST standard, and design completeness is not a security-effectiveness score.
Top comments (1)
"Do not confuse intent with permission" is the sentence I'd frame. A model can be technically correct and still be wrong about entitlement — and that's the gap most agent frameworks don't address.
The "deterministic enforcement should be outside the model's control" part is the key architecture decision. If the model can decide whether it's allowed to do something, it's not enforcement, it's a suggestion.
Curious how you'd handle the case where the model's request is valid but the target resource doesn't exist yet (e.g., it tries to write to a table that hasn't been created). Does the enforcement layer block it, or does it allow the operation and let the downstream error surface?