2938 Members
Join Permit's SlackNSA advisories do not usually land in an engineering team's planning backlog. They land when a failure pattern has become systematic enough that intelligence agencies feel the need to name it publicly. Careful Adoption of Agentic AI Services, published April 30, 2026 by NSA and counterpart agencies from the United Kingdom, Australia, Canada, and New Zealand (advisory PDF), is not about a specific vulnerability or a named threat actor. It is about a class of organizational error: deploying AI agents with authorization assumptions built for human users and static service accounts, then watching accountability disappear as agents act autonomously on that access.
The document is eleven pages and reads more like a post-incident pattern brief than a theoretical framework. It describes what is already happening — organizations granting agents broad standing credentials, relying on one-time permission checks at deployment, and operating delegation chains that no one can reconstruct after the fact — and it prescribes specific controls to stop it. The rest of this article breaks down what those controls actually demand.
Traditional IAM was designed around a mostly stable principal. A human user has an identity lifecycle, predictable interaction boundaries, and review rhythms that happen on a schedule: onboarding, role change, quarterly recertification, offboarding. Even service accounts, while risky, are at least conceptually static. The whole model assumes the actor category is known and bounded.
Agentic systems are not that category. The advisory defines agents as autonomous, goal-directed systems that can act without continuous human intervention, and explicitly notes they may spawn sub-agents and follow delegation chains that are not always visible to operators. That means identity, authorization, and accountability drift from "who has access?" to "what is this system doing right now, on whose behalf, with which inherited context?" The old assumptions do not fail at the edges; they fail in the center. NSA even states governance mechanisms made for human actors do not always translate to autonomous agents.
There is another subtle break: periodic permission review assumes behavior changes slowly, while agent behavior can change dynamically with context, tool outputs, prompt state, and orchestration flow. So the principal is not just "a faster service account." It is a different operational actor, and the advisory's architecture recommendations make sense only if you accept that premise.
If you compress the advisory into implementation obligations, four requirements stand out. First, each agent must be treated as a distinct principal with cryptographic identity, not a shared credential pool. NSA guidance literally says developers should construct each agent as a distinct principal with its own cryptographically anchored identity and unique keys or certificates, then maintain a trusted registry and deny access for identities or keys outside that registry. Shared credentials destroy non-repudiation and make post-incident attribution performative rather than forensic.
Second, credentials should be ephemeral and task-scoped. The advisory repeatedly warns about static or shared secrets and recommends replacing long-lived secrets with ephemeral credentials and using just-in-time credentials for high-impact or privileged actions. If a key sits in an environment variable for months, that is standing privilege by inertia, not controlled delegation.
Third, authorization has to happen per action, not once at deployment. NSA's own risk scenarios describe what happens when permissions are evaluated at startup and then reused: stale "allow" decisions become an exploit path. The guidance is explicit that identity and authorization should be verified continuously at runtime with a centralized policy decision point for each request. In blunt terms, giving broad access at startup is access provisioning, not authorization.
Fourth, high-impact actions need human gates. NSA guidance names concrete examples: system resets, network egress, deletion of critical records, and requests to delete logs or audit records. It also says the decision about where human approval is required must be made by designers and operators, not delegated to the agent itself. "High-impact" in practice means high blast radius, hard reversibility, or high compliance consequence.
"Continuously verify identity and authorization at runtime" sounds clean on paper. In real environments, it is the most difficult control in the document. Most organizations have identity infrastructure that issues credentials and does coarse grants. Very few have a runtime authorization plane that can evaluate context-rich policy at each tool call with latency low enough not to break the workload.
The hard part is not writing policy statements. The hard part is operating policy as a live distributed system. You need low-latency decisioning, reliable context ingestion, replay-safe request signatures, and consistent enforcement across gateways, services, and agent runtimes. If policy becomes unavailable, do you fail closed and halt critical workflows, or fail open and accept risk? Either answer has operational cost.
The advisory's risk scenarios show why this is not optional: it highlights cases where entitlements checked only once at startup let attackers exploit stale authorization and move laterally through adjacent agent functions. Continuous authorization is not an "advanced maturity bonus"; it is the control that separates bounded incidents from system-wide confused-deputy failures.
Single-hop delegation is comparatively manageable. A user authorizes an agent, the agent presents a token, and a resource server validates claims against policy. That path is the easy one, and existing OAuth patterns can support it when implemented carefully.
The break appears in orchestration. Agent A calls Agent B, which invokes Service C. Service C often sees B's credential and local claims, but not full upstream intent, consent boundaries, or original user constraints unless the architecture deliberately carries and verifies that chain. NSA points toward this problem by discussing hidden delegation chains, sub-agent spawning, and accountability failure when distributed decisions and fragmented logs obscure causality.
This is exactly where standards substrate work matters. NIST's NCCoE concept paper from February 2026 frames a project around agent identity and authorization, including access delegation and standards such as OAuth 2.0/2.1 extensions and SPIFFE/SPIRE for workload identity. It is the right ongoing work — but it is upstream infrastructure, not a finished answer.
The accountability test is simple and uncomfortable: if Service C executes a damaging action, can you prove quickly and cryptographically who authorized it and under what constraints? If the answer requires days of forensic reconstruction across mismatched logs, you already have a non-repudiation failure.
This is where the advisory becomes an architecture decision, not a policy memo. Meeting these controls requires an enforcement plane that evaluates policy at action time. An identity provider can authenticate principals; it does not, by itself, perform fine-grained per-request authorization with evolving context and chain-of-delegation semantics.
A PBAC-style engine in front of agent tool calls and downstream APIs gives you that runtime decision layer. Concretely, the flow looks like this: the agent receives a task, requests a task-bounded credential, presents identity plus context for a specific operation, and gets an allow/deny decision at the moment of action. High-impact operations are routed to explicit approval states instead of direct execution. Decision logs bind user, agent, action, resource, and policy version, which is what you need for actual accountability rather than a comforting dashboard.
That is the practical alignment with NSA guidance: distinct cryptographic identities, no standing broad privilege, per-action checks, and mandatory human gates where the blast radius demands it.
It says agentic AI should be adopted cautiously and incrementally, starting with low-risk, non-sensitive tasks, and that organizations should avoid broad or unrestricted access. It identifies five risk spaces — privilege, design and configuration, behavior, structural, and accountability — then gives lifecycle controls across design, development, deployment, and operations. The advisory PDF is eleven pages and readable in under an hour.
At minimum: assign distinct cryptographic identity per agent, eliminate long-lived shared secrets in favor of just-in-time ephemeral credentials, enforce least privilege per action with runtime re-evaluation, and require human approval for high-impact actions. Then add accountability logging that preserves decision chains across agent hops. The advisory does not prescribe exact technology choices, so the architecture decisions are yours to make within those requirements.
Treat each agent as its own principal with cryptographically anchored identity, validate inter-agent and agent-to-service calls — for example with mutual TLS — maintain a trusted identity registry, and deny unknown identities and keys. Identity is treated as a primary security boundary, not metadata. The advisory specifically warns against shared credentials because they make attribution impossible after the fact.
Least privilege for agents means giving only the minimum permissions required for the specific task, scoping those permissions narrowly by resource and time, and revoking elevated rights immediately after sub-tasks complete. NSA ties this to per-request verification at runtime rather than a permission grant at onboarding, because static grants cannot account for how agent context changes during execution.
Continuous authorization. It explicitly calls for continuously verifying identity and authorization at runtime using a centralized policy decision point for each request. Provisioning once at startup is specifically identified as a failure pattern in the risk scenarios, not a sufficient baseline.
The advisory directly names system resets, network egress, deletion of critical records, and deletion of logs or audit records. More broadly: any action with high blast radius, low reversibility, or significant compliance consequence qualifies. The advisory also specifies that the threshold for human approval must be decided by system designers and operators, not inferred or decided by the agent at runtime.
They are complementary and address different layers. The NSA advisory is operational guidance — what controls to implement and what failure modes to avoid. The NIST NCCoE concept paper, published in February 2026, works at the identity standards layer — how OAuth 2.0/2.1 extensions, SPIFFE/SPIRE, and related protocols should be adapted to provide cryptographic agent identity and delegation semantics. Teams need both: the NSA advisory to understand the security floor, and the NIST work to understand the technical building blocks.
Full-Stack Software Technical Leader | Security, JavaScript, DevRel, OPA | Writer and Public Speaker
