The NCCoE Published 10 Design Tenets for Agentic Identity. Six of Them are Already Verifiable.

The NCCoE just published ten "Design Tenets for Agentic Identity" as part of their Accelerating the Adoption of Software and AI Agent Identity and Authorization project. They cover everything from distinct agent identification to immutable evidence chains.

You'd think the problem is ahead of us, new protocols to design, standards to write, infrastructure to build. But six of these ten tenets map directly to cloud configuration properties that exist today, in the IAM and logging infrastructure you already run.

The gap is missing verification.

What's in scope

The ten tenets split into two groups when you ask: can a configuration verifier check this?

Four tenets are runtime architectural concerns. They require new infrastructure that doesn't exist yet in most organizations. Six tenets describe properties of IAM policies, trust relationships, credential lifecycles, and logging infrastructure that are already deployed and already misconfigured.

Here's the split.

Tenet 02: Delegation and Attenuation

"As authority is delegated down to sub-agents or downstream services, scopes attenuate so that downstream entities can never claim more authority than the parent."

The NCCoE frames this around cryptographic delegation chains. But the attack it describes, a downstream entity claiming more authority than its parent is the confused deputy problem, and it's been endemic in AWS cross-account trust since before agents existed.

An IAM role trusting a third-party account root principal without sts:ExternalId or aws:SourceAccount conditions is maximally exposed. Any customer of the same third-party vendor can assume your role through the vendor's IAM system. The Microsoft Midnight Blizzard 2024 breach exploited exactly this: a legacy cross-tenant trust without per-customer binding, pivoting from a test tenant to production Exchange mailboxes.

The verifiable properties:

• Third-party trust has confused deputy protection. Every role trusting an external account root principal must have sts:ExternalId or aws:SourceAccount conditions. Without them, the blast radius is the entire third-party account's principal population.
• Service principal trust has source binding. Roles trusting AWS service principals must have aws:SourceArn or aws:SourceAccount conditions. Without them, any account using that service can assume your role.
• OIDC federation validates immutable claims. OIDC trust policies must validate the sub claim, not just the issuer. A mutable subject claim lets any workflow in the federated IdP assume the role.
• Cross-account ExternalId is scoped. ExternalId values must be unique per trust relationship. A wildcard ExternalId provides zero protection.

These are boolean predicates on your current IAM configuration. You don't need a new delegation protocol to check them.

Tenet 03: Least and Zero Standing Privilege

"Agents operate with zero standing privilege, holding no persistent rights when idle. Access is bounded strictly to the minimum scope required for a designated task."

Zero standing privilege requires JIT provisioning infrastructure that most organizations don't have. But least privilege, the minimum scope for a designated task is verifiable right now, where most organizations fail.

A Lambda execution role with AmazonS3FullAccess attached to a function that reads from a single bucket is a risk. When combined with a public function URL or a compromised dependency, that over-privileged role converts a single function compromise into account-wide lateral movement.

The verifiable properties fall into three categories:

Overprivilege detection. Execution roles with wildcard actions, AWS-managed FullAccess policies, or permissions that exceed observed call patterns. Third-party vendor roles that are dormant or carry permissions beyond what the integration requires.

Escalation path enumeration. This is the one most organizations miss. Twenty-plus distinct AWS privilege escalation paths exist such as iam:AttachRolePolicy, iam:PutRolePolicy, iam:CreatePolicyVersion, iam:PassRole combined with service-specific launch permissions, codebuild:StartBuild with source repository write access. Each one lets a principal reach permissions it wasn't directly granted.

The CodeBuild vector has a principal with codebuild:StartBuild on a project, plus write access to the project's source repository, can inject a malicious buildspec that runs under the project's service role. This doesn't require iam:PassRole. The service role is already attached. The attacker only changes what it executes.

Blast radius scoring. Even where overprivilege can't be eliminated, the blast radius of a compromised identity can be measured. How many resources can this identity reach? How many escalation paths does it have? What's the compound severity when multiple controls fail?

Tenet 04: Short-Lived, Dynamic and Revocable Authorization

"All access grants are Just-In-Time, time-bounded and audience-specific."

Dynamic JIT authorization is a runtime concern. But the prerequisite that services use short-lived credentials instead of long-lived access keys is a configuration property.

The verifiable property is direct: service-to-service access must use STS temporary tokens, IAM Roles Anywhere certificates, or OIDC federation. A service identity using long-lived access keys fails. A stolen temporary token expires automatically; a stolen access key provides indefinite access until someone rotates it.

SSO permission set session duration is also verifiable. An SSO session configured for 12 hours when the task takes 30 minutes is standing privilege with a time delay.

Tenet 08: Deterministic Access Decisions

"Organizations maintain deterministic capabilities as the primary mechanism for making access decisions in agentic scenarios."

This tenet targets LLM-based authorization using probabilistic reasoning to decide whether an agent should access a resource. The NCCoE's position: don't.

IAM policies are already deterministic. The question is whether they stay that way as agents interact with them. The verifiable properties are the structural integrity of the policy layer:

• SCP deny boundaries exist and are protected. Service Control Policies that enforce organizational deny rules can't be modified by the entities they constrain.
• Trust policies have explicit conditions. Every cross-account and federated trust policy specifies exact conditions rather than relying on implicit grants.
• No escalation path bypasses the policy evaluation. The twenty-plus escalation vectors from Tenet 03 are also relevant here. Each one represents a path where the deterministic policy evaluation can be circumvented.

The agentic risk this tenet addresses is if an LLM decides access based on a prompt, that decision is manipulable via prompt injection. But the defense is ensuring the deterministic layer underneath is sound.

Tenet 09: Continuous Monitoring

"Systems monitor agentic access and provide detection and warnings of potentially anomalous behavior."

This is the most extensively verifiable tenet. The question is whether it covers every service the agent touches.

Across AWS alone, logging controls span CloudTrail, API Gateway, ECS, Lambda, CodeBuild, Bedrock, CloudFront, S3, RDS, Redshift, EKS, VPC Flow Logs, Route53, WAF, ElasticSearch, MSK, Neptune, DocumentDB, and EMR. Each service has its own logging configuration, and each one can be independently disabled.

The compound risk matters more than any individual control. A trail that's stopped plus missing Object Lock plus no StopLogging alarm creates a detection blind spot. The exposure lives in these compound states. Any single control might be excused as an oversight, but two or three together represent a systematic failure in monitoring coverage.

Multi-cloud makes this worse. GCP logging (BigQuery audit, CloudSQL, DNS, Gemini), Azure (Activity Log, Firewall, Storage, SQL), and M365 (Exchange, Purview) each have their own logging configurations that need independent verification.

What's not verifiable at the configuration layer: whether the monitoring thresholds are calibrated for agentic workloads. An agent operating at machine speed produces orders of magnitude more events than a human. Static alert thresholds tuned for human activity patterns will either fire constantly (alert fatigue) or miss the signal. That calibration is a runtime concern.

Tenet 10: Immutable Evidence

"The enterprise maintains an unbroken, tamper-evident chain of custody and append-only body of evidence."

This tenet has the deepest verifiable coverage. The entire logging integrity stack is configuration:

• Log file digest validation is enabled. CloudTrail digest files detect post-delivery tampering.
• Logs are retained beyond the default window. The 90-day CloudTrail Event History is insufficient for forensics.
• Log buckets have retention policy locks. GCP logging buckets with locked retention policies can't have their retention shortened.
• SCPs deny logging disruption. Service Control Policies must deny StopLogging, DeleteTrail, and UpdateTrail to non-breakglass roles.
• Cross-account replication exists. Logs replicated to a separate logging account survive compromise of the source account.
• Trail is actively logging and multi-region. A stopped trail is the most critical finding — it means evidence collection has ceased.

The compound states are important here. A log bucket without Object Lock, combined with missing MFA Delete and no Deny on DeleteObject, creates a tamper path. An attacker who reaches the bucket can delete evidence. A log bucket that's publicly accessible plus missing versioning plus no Object Lock creates a destruction path. A stopped trail combined with missing Object Lock and no StopLogging alarm means evidence is both not being collected and the gap isn't being detected.

Each of these compound states is critical severity, because they represent not just a misconfiguration but a systematic failure in evidence integrity.

The four that aren't verifiable (yet)

For completeness, the four tenets outside configuration verification scope:

Tenet 01 — Distinct Agent Identification. Agent identity issuance and cryptographic binding to workloads is a provisioning concern, not a configuration check. Today's cloud IAM doesn't distinguish between a role assumed by an agent and one assumed by a service.

Tenet 05 — Human-in-the-Loop Triggers. Approval workflows and escalation gates require a workflow orchestration layer. No configuration property represents "pause and ask a human when risk exceeds this threshold."

Tenet 06 — Mandates and Constraints. Cryptographically signed task-scoping artifacts are new infrastructure. The signing keys could theoretically be verified (is the KMS key configured?), but no cloud service today consumes mandate documents.

Tenet 07 — Architectural Separation of Policy from Reasoning. This is about LLM architecture. Ensuring the prompt processing pipeline can't manipulate the credential and authorization layer. It's the most important tenet for agents, and sits outside cloud configuration.

The gap

The NCCoE tenets are a useful framework, but they risk creating the impression that agentic identity is a future problem requiring new standards. Six of the ten tenets describe properties of infrastructure you deploy today.

The question is whether your current IAM configuration satisfies the ones it already could.