Loading
Loading
3366 Members
Join Permit's SlackQuick answer: Treat an AI agent as a privileged non-human identity: its own identity, scoped grants, revocable human-to-agent delegation, and logged decisions. Use this model when agents call tools that read sensitive data or change systems. Don't apply it to agents limited to public data or a sandbox, and don't read it as a certification claim: it is a design pattern your auditors will assess.
Distinct agent identity, least privilege, attributable delegation, and forensic authorization logs, not shared API keys or "the agent is logged in as me." Treat agents as privileged non-human identities with scoped grants, revocable human→agent authority, and decision evidence that answers: who delegated, which agent acted, which tool was called, which resource was touched, allow or deny, and why.
Most teams designed IAM for humans, service accounts, CI jobs, and API integrations, not software that chains actions and calls tools at machine speed. Then agents got wired into the same primitives: long-lived API keys, shared service accounts, and browser sessions where the agent is effectively "logged in as me."
That model fails.
A shared key defines the blast radius. If an agent can read every customer record, pull support tickets, query production telemetry, call billing APIs, and update CRM objects, then one compromised workflow can exercise all of that access immediately. The original prompt may be harmless. The credential is not.
"Logged in as me" creates another problem: it collapses human identity and agent identity. In the audit trail, it looks like Alice did everything. Maybe Alice clicked the button. Maybe her agent acted on her behalf. Maybe a prompt-injected tool pushed the agent into an action Alice never intended. If the system only records Alice, accountability dies.
Agent workflows are not single API calls. One prompt can fan out across CRM, tickets, docs, billing, issue trackers, incident workflows, and chat. Each step may touch a different tenant, resource, data class, and risk level. A login check at the start does not answer whether this specific agent should call this specific tool on this specific resource right now.
The predictable result is privilege accumulation. Agents get broad access because scoping tools is hard: read-only becomes write, then export, then admin, then production. Eventually the agent is a privileged non-human identity with less governance than a junior engineer.
This is not AGI hype. It is access control. If an agent can call tools, move data, or take action across enterprise systems, it needs distinct identity, least privilege, explicit delegation, and decision logs.
NIST NCCoE's concept work on software and AI agent identity and authorization, including the February 2026 concept paper direction, frames the problem in operational terms: identify agents, authorize actions, delegate access safely, and log what happened.
This is an engineering alignment map, not a certification claim. NIST does not require Permit, and using Permit does not make you NIST certified or compliant. The focus areas map cleanly to the controls platform teams need.
The NCCoE concept paper describes the identification goal this way:
Identification of AI and Software Systems. Leveraging existing standards, the project will explore available means to identify software and AI agents such that access management systems can distinguish between agent and human identities and effectively manage the range of actions an agent may take from controlled human-in-the-loop approval to autonomous action in response to an input.
That is the starting point for treating an agent as its own privileged identity rather than a borrowed human session. The paper is a concept document seeking input, not final guidance.
| Focus area | What it asks | AuthZ practice |
|---|---|---|
| Identification | Distinguish agent from human; manage action range metadata | Distinct agent / client / instance identity; do not reuse human user IDs as the sole principal |
| Authorization | Grant and enforce rights/entitlements for the agent | Policy-based per-tool / per-resource / per-tenant decisions; least privilege; trust ceilings |
| Access delegation | Link human identities to agents while keeping accountability | Explicit, scoped, revocable human→agent grants; min(human, agent, admin ceiling) |
| Logging and transparency | Attribute actions to the non-human entity with visibility | Decision logs: human + agent + tool + resource + allow/deny + reason + HITL/consent |
Separate the principals: the human delegator, the agent identity, the agent instance or session, the runtime (MCP client, workflow runner, hosted agent), and the target resource. If logs only say "Alice updated account 456," you cannot tell whether Alice acted directly, an agent acted on her behalf, or a shared credential was used by a background process.
Distinct agent identity also carries authorization metadata: owner, environment, allowed tools, risk tier, tenant boundary, and session expiration.
Once the agent has identity, the question is not "can this agent access the system?" It is: can this agent, acting for this human, call this tool, on this resource, in this tenant, at this time?
Examples:
The tool call is the enforcement point. Login is not enough. A valid client connection does not prove the action is allowed.
Agents often act for a human. That does not mean they should inherit everything the human can do.
Delegation should be explicit, scoped, time-bound, and revocable. A useful model is:
effective_permission = min(human_permission, agent_permission, admin_ceiling)
The human's permission is a ceiling, not a grant by itself. If Alice cannot access an account, her agent cannot access it either. But even if Alice can access it, the agent still needs its own scoped grant. Admin policy can define ceilings neither Alice nor the agent can exceed.
This avoids the "logged in as me" trap. Alice is accountable for delegation. The agent is accountable for action. Policy explains the decision.
Agent logging cannot stop at "tool was called." Forensics require authorization evidence: which human delegated, which agent and session acted, which tool and MCP server or backend were involved, which resource and tenant were targeted, allow or deny, which policy/trust/consent condition drove the result, whether HITL was required or captured, and whether the grant was later revoked.
Activity logs tell you what happened. Decision logs tell you why it was allowed or denied. For security review and incident response, the "why" is usually the hard part.
Agents create a simple mismatch: the human may be trusted, but the workflow may not be. A senior engineer may deploy to production. That does not mean every coding agent acting for that engineer should have standing production deployment access.
A trust ceiling is an admin-defined maximum risk level a human can grant to an agent. Alice may delegate low-risk read operations and medium-risk ticket updates inside assigned accounts, but not high-risk actions such as exporting PII, deleting records, changing billing terms, or modifying production infrastructure. Only specific admins can enable high-risk tools for specific agents under policy constraints.
This is not about distrusting Alice. It is about controlling delegation. Agents act faster, call more tools, and compose more steps than humans usually do manually.
Human-in-the-loop approval is useful, but it is not a substitute for policy. HITL should be modeled as an authorization obligation: the policy says the action is not allowed unless approval, consent, or step-up verification is present.
Exporting customer PII, submitting payments above a threshold, deleting production resources, merging to protected branches, or sending external customer emails may require confirmation. If approval is missing, deny or return "approval required." If approval exists, allow and log the approval context. "Ask the user" is not enough unless the authorization system can see and audit that consent.
Zero standing privilege means the agent does not hold broad always-on power. Prefer short-lived, task-scoped grants: read these five tickets for 30 minutes; query logs for payments-api during INC-789; open a PR in repo checkout, but cannot merge; draft refund records, but cannot submit them without approval.
The more capable the agent, the less acceptable standing credentials become. A user permission can be a ceiling. The agent still needs its own scoped grant.
MCP is becoming a common interface layer for tools. That makes it a natural place to get authorization right, or to repeat the service-account mistake at a larger scale.
OAuth and client authentication answer: can this client connect? That is connection-level authentication. You need it. But it is not tool authorization.
Tool authorization asks: can this agent, acting for this human, call this tool, against this resource, right now?
An MCP client may be valid. The user may be logged in. The MCP server may be reachable. None of that proves the agent should call export_customer_data, create_payment, delete_cluster, or merge_pull_request.
You need both connection-level AuthN and per-tool AuthZ.
A gateway policy enforcement point in front of MCP servers is a practical architecture. It avoids rewriting every MCP server. The gateway can evaluate policy before tool calls, enforce consent or delegation requirements, apply trust levels or ceilings, and produce audit records that include the agent, human, tool, server, and allow/deny result.
That is the model behind Permit's MCP Gateway:
Put a PEP where the tool call happens. Then evaluate authorization using the same fine-grained policy model you already need for product access control. If the AI path bypasses your authorization layer, you have built a privileged side door.
APRA's April 2026 industry letter made a similar point from a regulatory supervision angle: identity and access management has not yet fully adjusted to non-human actors such as AI agents, and controls over agentic and autonomous workflows are becoming part of security expectations.
That direction is consistent with treating agents as privileged identities. IAM and authorization cannot stop at human users. They need to cover non-human actors, delegated authority, autonomous workflows, and evidence.
This is not legal advice, and it is not a claim that using Permit makes an organization APRA compliant or certified. For more on the broader access-control bar for AI systems, see /blog/ai-era-same-bar-higher-bar and /blog/dora-nist-access-control.
Use this checklist:
This is where Permit fits. Permit separates the control plane from the data plane, so teams can manage policy centrally while enforcing authorization close to the application and tool-call path. The hybrid PDP model lets authorization decisions run in your environment. OPAL distributes realtime policy and authorization data updates, so permission changes and revocations can propagate without making every check depend on a remote SaaS call.
Relevant docs:
For agentic systems, the pattern is consistent: tool call → PEP → PDP evaluates human, agent, tool, resource, tenant, trust, and delegation → allow, deny, or require consent/HITL → log the decision.
For architecture background, see /blog/pep-pdp-architecture. For the delegation and evidence model, see /blog/human-agent-delegation-audit-trail.
The point is not to create a one-off security model for AI. The point is to stop letting AI bypass the access-control model you already know you need.
AI agents are privileged identities. Treat them that way.
Give them distinct identity. Grant least privilege. Make human→agent delegation explicit, scoped, and revocable. Enforce authorization at runtime, not only at login. Capture forensic decision logs that explain who delegated, which agent acted, which tool was called, what resource was touched, whether the action was allowed or denied, and why.
The right architecture is not a pile of shared keys. It is the same fine-grained authorization control plane you trust for your product, extended to agents and MCP tool calls.
Permit can help with that: hybrid PDP enforcement, realtime policy and data distribution with OPAL, decision logs, and MCP Gateway enforcement where MCP is part of the tool path.
This does not guarantee NIST, APRA, SOC 2, or any other compliance status or certification. From an engineering standpoint, the direction is clear: agents are privileged non-human identities, and privileged identities need authorization.
Co-Founder / CEO at Permit.io
