AIUC-1 Q2 2026 Update: Agent Identity, Zero Trust, and What Governance Actually Requires

The AI security framework landscape has matured significantly over the past two years. Google’s Secure AI Framework (SAIF), CSA’s AI Controls Framework, and OWASP have built the risk taxonomy and threat modeling foundation that practitioners rely on daily. That work is critical and continues to evolve. What has been harder to find is a standard that governs how AI agents actually behave inside enterprise environments, with operational requirements, testing criteria, and accountability mechanisms behind it. 

AIUC-1 is the closest thing the industry has produced to filling that gap. The Q2 2026 update added controls that address something that has become a critical problem in real deployments: agent identity and permissions management. This post covers what AIUC-1 is, who is behind it, what changed in Q2, and how security, identity, and GRC teams can use these controls operationally.  

What Is AIUC-1? 

AIUC-1 is the first compliance standard built specifically for AI agents, not AI in general and not large language models in isolation. Agents execute multi-step workflows autonomously, call APIs, spawn sub-agents, and act inside enterprise infrastructure with real authority. The risk surface of an agent is fundamentally different from a prediction model or a conversational interface, and AIUC-1 was built to address that directly. 

The standard covers 50+ technical, operational, and legal requirements across six risk domains: data and privacy, security, safety, reliability, accountability, and society. It was developed with technical contributors from MITRE, Cisco, Stanford's Trustworthy AI Research Lab, MIT Sloan, Google Cloud, and Orrick. Over 120 consortium members contributed to the Q2 update through technical sessions and peer-review, including Salesforce, JP Morgan, Oracle, MongoDB, HubSpot, and UiPath. Schellman is the first authorized auditor. The standard updates quarterly because the agent threat surface is moving faster than annual release cycles can track. 

It is also worth being precise about terminology. Non-human identities (NHIs) and agentic identities are related but distinct concepts. NHIs are the broader category: service accounts, API keys, OAuth tokens, workload identities, and machine credentials of all kinds. Agentic identities are a specific and newer subset: identities created for autonomous AI agents that can reason, plan, and take multi-step actions. Agentic identities carry unique risks because the agent behind them can initiate actions, spawn child agents, and chain together capabilities across systems in ways that a static service account cannot. Both categories need governance, but they need governance that accounts for their different behavior profiles. 

The Q2 2026 Update: Agent Identity and Permissions 

The Q2 2026 update focused on three areas: MCP security, third-party risk management, and agent identity and permissions. The identity and permissions controls are the most operationally significant for organizations deploying agents in production today, because they address the foundational question that all other access controls depend on: can you reliably identify what is making an access request, and can you enforce what it is allowed to do at the moment of that request? 

Why This Update Is Timely 

Agents are running in production across enterprise environments, executing workflows across connected systems, spawning sub-agents, and inheriting permissions that were never designed for autonomous actors. The governance infrastructure for these systems has been improvised. AIUC-1 is starting to formalize it with controls that map directly to operational decisions security teams are already being asked to make.  

The Identity and Access Controls 

Five controls are directly relevant to agent identity, access, and Zero Trust architecture. Two are new in Q2 2026. Three are existing controls that the new identity layer now connects together. 

New Controls (Q2 2026)  

A003.3  Agent Identity Governance (NEW Q2 2026) 

Each agent requires a unique, cryptographically verifiable identity. Without this, there is no reliable way to distinguish one agent from another, attribute actions to a specific agent, or detect impersonation across a multi-agent workflow. The control formalizes the requirement that every agent can be distinctly identified and authenticated at the point of access, not just assumed to be what it claims to be. 

Britive:  Manages non-human identity and agentic identity lifecycles across cloud environments, giving every agent a distinct, auditable identity from provisioning through decommission.  

***A note on A003.3 and cryptographic identity: this does not mean only vendors who control the underlying compute can satisfy this requirement. The cryptographic verification happens at the identity layer, not the compute layer. Open standards like SPIFFE/SPIRE issue short-lived X.509 certificates or JWTs to workloads regardless of where they run. Cloud-native mechanisms like AWS IAM workload identity, Google Workload Identity, and Azure Managed Identity all issue cryptographically verifiable tokens based on execution context. OIDC tokens issued at runtime give agents a signed, verifiable identity claim that any downstream system can validate without owning the infrastructure. 

A003.3 requires that each agent has a unique, verifiable identity. It does not specify who issues the cryptographic credential. A governance platform can consume identity assertions from SPIFFE, cloud-native workload identity, or OIDC and use them as the verified identity anchor for access decisions. The verification happens upstream. The governance layer sits on top of it. 

The harder operational question A003.3 is really driving at is whether your agent deployment pipeline provisions cryptographic identity at all. Many teams are still deploying agents with no identity attestation mechanism, just a service account name and a shared secret. That is the gap this control is designed to close, regardless of which infrastructure layer closes it.  

A003.4  Agent Access and Permissions Management (NEW Q2 2026) 

Agent privileges must be scoped and time-limited using just-in-time permissions architecture. An agent holding persistent access to a system it only needs for a single task is an open attack surface, and the problem compounds when that agent can spawn child agents that inherit its permissions. This control requires permission-ready architecture as the implementation model, with just-in-time access as the specified approach. Zero Standing Privileges is the architecture that satisfies this requirement. 

Britive:  Provisions access at the moment it is needed and revokes it automatically when the task is complete, across cloud platforms and SaaS systems, for both NHI and agentic identities.  

Existing Controls (Now Connected by the Identity Layer) 

A003  Data Access Controls 

Restricts what data an agent can reach based on context, role, and task scope. Without fine-grained data access controls, agents operating across connected systems pull far more than they need for any given task. The new identity controls give this requirement the subject layer it was missing: now you know which agent is making the request and can evaluate whether that request is within its defined scope. 

Britive:  Enforces least privilege data access policies for both NHI and agentic identities across multi-cloud environments. 

D003  Tool Access Controls 

Restricts which tools and services an agent can invoke. An agent with broad tool access in a connected system creates lateral movement risk, particularly in agentic workflows where one agent can hand off control to another. Scoping tool access per session and per task is how you contain that risk. 

Britive:  Scopes permissions per session and per task so an agent operating in one context cannot invoke capabilities outside its defined scope. 

B006  Permission Enforcement 

Policy definition is not enforcement. This control requires that permissions are actively enforced at runtime, not just documented at design time. The gap between what a policy says and what is actually enforced at the moment an agent attempts to access a resource or invoke a tool is where incidents happen. 

Britive:  Closes the gap between what a policy says and what is actually enforced when an agent attempts to access a resource, call an API, or invoke an MCP tool. 

Unified Agent Inventory and Runtime Governance 

One of the practical challenges in governing agentic identities is that agents are being deployed from multiple sources simultaneously. AWS AgentCore, Google Cloud, Azure, enterprise automation platforms, and internal development teams all create agents through their own registries and directories. A governance model that only covers agents deployed through a single registry leaves the rest of the environment ungoverned. 

Britive operates its own agent registry, but the more important capability for enterprise security is the ability to ingest agent identity and metadata from all of these external sources and build a unified inventory across them. When an organization can see every agent running across their environment regardless of where it was provisioned, they can build entitlement policies that apply consistently and enforce those policies at the moment of access rather than after the fact. 

This unified inventory is the foundation for several downstream capabilities that AIUC-1 controls are designed to require. Entitlement policies can be constructed based on agent identity, the task context, the specific MCP tools or APIs being invoked, and the data classifications involved. Runtime enforcement means that when an agent attempts to call an API or invoke an MCP tool, the access decision is evaluated in real time against those policies, not assumed based on standing permissions. Full audit trails capture what each agent accessed, which tools it invoked, and what data it reached, creating the visibility that both compliance and threat detection depend on. 

This approach also addresses MCP tool governance and API governance at the moment of invocation, which is where AIUC-1 control D003 applies. Knowing that a tool exists is not sufficient. Governing which agents can invoke that tool, under what conditions, and with what scope of data access is the operational requirement, and it only works when you have a complete and unified picture of agent identity across your environment. 

What Unified Agent Governance Looks Like 

Complete inventory: Every agent running in the environment, regardless of which cloud, platform, or team deployed it. 

Policy enforcement: Entitlement policies built from that inventory and enforced at the moment of each access request or tool invocation. 

Runtime visibility: A full audit trail of what each agent accessed, what it did, and when, for both compliance reporting and threat detection. 

MCP and API governance: Access decisions made at the moment of invocation, not assumed from standing permissions. 

The Zero Trust Connection 

The Zero Trust principle most relevant to agentic AI is that no entity, human or non-human, should hold standing access to anything. Every access request should be evaluated in context, scoped to the minimum required, and time-limited to the duration of the task. A003.4 operationalizes that directly for agents. 

The challenge with applying Zero Trust to agentic identities is that agents can spawn other agents, inherit permissions transitively, and operate across system boundaries continuously. A human user logs in, does something, and logs out. An agent can run for hours, spawning child agents that inherit its scope, calling APIs across multiple systems, and leaving behind a permissions trail that was never explicitly reviewed or approved. The identity layer added in Q2 is what makes Zero Trust enforceable in that context. Without the ability to reliably identify each agent and enforce its specific entitlements at runtime, the rest of the access control framework is built on an assumption that cannot be verified. 

It is also important to distinguish between NHI governance and agentic identity governance, even within a Zero Trust framework. NHIs like service accounts, API keys, and OAuth tokens have relatively predictable behavior profiles. They call the same APIs in the same patterns. Agentic identities behave differently: they reason, plan, and take actions that may not have been explicitly anticipated at provisioning time. Governance for agentic identities needs to account for that dynamic behavior, which is why runtime enforcement at the moment of each tool invocation or API call matters more than static policy definition. 

For Auditors, GRC Teams, and CISOs 

As security teams, CISOs, and application teams look to modernize their identity security programs, one of the most important decisions they face is vendor selection in the agent identity and NHI governance space. The questions below are designed to be used in audit assessments, vendor evaluations, and internal security reviews to ensure the model you are building toward is genuinely Zero Trust, not just Zero Trust in name. They cut through marketing language and surface the operational reality of how access is actually governed. 

They also help distinguish between three categories of solutions that often get conflated: visibility-only tools that can tell you what NHIs and agents exist but cannot enforce anything, traditional JIT approaches that rely on credential rotation, vaults, and time-bound service accounts but leave standing entitlements in place, and true runtime governance that enforces access at the moment of request with no standing permissions. 

The Identity Triad: Three Questions Every Agent Must Be Able to Answer 

01.  WHO IS THIS AGENT?  [A003.3]  Does every agent have a unique, cryptographically verifiable identity, or is it just assumed? 

02.  WHAT CAN IT ACCESS RIGHT NOW?  [A003.4]  Is access provisioned just-in-time and revoked when the task ends, or does it hold standing permissions? 

03.  WHAT DID IT DO?  [B006]  Can you produce a full, attributable audit trail of every action this agent took, on demand? 

If you cannot answer all three for every agent in your environment, your agents are ungoverned. 

The ZSP Test  [A003.4 / NIST 800-207] 

If I asked you to show me all the systems Agent X can currently access, would that list be zero -unless Agent X is actively running a task right now? 

If the answer is not yes, your agents have standing access. That is the risk. 

Follow-up for vault-based approaches: when the vault issues a credential to Agent X, does that credential map to a service account that already has standing permissions to those systems -or are the permissions themselves provisioned at that moment and removed when the task ends? 

A traditional vault gates the key. Zero Standing Privileges removes the lock entirely. Vault-based approach can answer the first question favorably while still relying on pre-provisioned service accounts with standing entitlements sitting behind a vault door. The follow-up closes that gap. Credential rotation is not entitlement removal. That distinction is what separates genuine ZSP architecture from a vault with a shorter timer. 

On Inventory and Discovery 

These questions establish whether an organization has a complete picture of its agent and NHI environment. 

Anchor Questions 

1.  Can you show me every agent and non-human identity running in our environment right now, including those deployed by third-party tools, cloud services, and teams other than your own? 

2.  If a new agent was deployed in a cloud environment we do not directly control, how long before you would know about it? 

3.  Do you have a single inventory that covers both NHIs (service accounts, API keys, OAuth tokens) and agentic identities, or are they tracked separately? 

On Access and Permissions 

These questions probe whether access is genuinely time-limited or just credential-rotated. Credential rotation and time-bound secrets are not the same as Zero Standing Privileges. In a credential rotation model, the service account still holds its permissions continuously; only the secret that unlocks it changes. In a true ZSP model, the entitlement itself does not exist until the moment it is needed. 

Anchor Questions 

1.  Do our agents and service accounts hold standing permissions to systems between tasks, or is every access provisioned at the moment of need and revoked when the task is complete? 

2.  If I asked you to show me all the systems Agent X can currently access, would that list be zero unless Agent X is actively running a task right now? 

3.  When a credential or secret expires in your environment, does the underlying permission also expire, or does the next credential inherit the same standing access? 

4.  Can a sub-agent inherit broader permissions than the parent agent that spawned it? What controls prevent that? 

On Runtime Enforcement 

These questions distinguish between tools that observe and report versus tools that enforce at the moment of access. Knowing that a service account has excessive permissions is useful. Preventing it from exercising those permissions at runtime is governance. 

Anchor Questions 

1.  When an agent attempts to call an API or invoke an MCP tool, is an access decision made in real time, or is access granted based on standing permissions that were set at provisioning? 

2.  If an agent attempts to access a resource it is not entitled to, what happens? Does it fail immediately, or does it succeed and get logged for review later? 

3.  Can you enforce different access policies for the same agent depending on what task it is executing and what data is involved? 

On Audit and Threat Detection 

These questions establish whether the organization has the audit trail and detection capability that both compliance and incident response require. 

Anchor Questions 

1.  If I asked you to produce a complete audit log of everything Agent X accessed and every tool it invoked last Tuesday, how long would that take? 

2.  Can you tell the difference between a human identity and a non-human identity in your audit logs? Can you tell the difference between a static NHI and an agentic identity? 

3.  If an agent's behavior changed unexpectedly, for example calling APIs it has never called before or at an unusual time, would your system detect that as anomalous? 

For CISO Rule-of-Thumb Questions to Ask Their Teams 

These are simplified versions of the above, designed to be asked in any security review or board conversation without requiring deep technical background. 

Simple Questions That Surface Real Answers 

1.  Do any of our agents or service accounts have access to systems they are not actively using right now? If yes, that is standing access. 

2.  If an agent we deployed last month was compromised today, how long before we would know, and what is the list of systems it could have reached? 

3.  Does our current tooling tell us what our agents and NHIs can do, or does it also control what they are allowed to do in real time? 

4.  As we modernize identity security with JIT access, ask: does the entitlement disappear between tasks, or just the credential? Those are very different things. 

5.  Do we govern our agentic identities the same way we govern our human identities, with provisioning workflows, least privilege policies, and audit trails? 

What the Standard Is Honest About 

The peer-review commentary accompanying the Q2 update was honest in stating that best practices for agent identity and access management are still maturing, and the controls will continue to be refined as the industry evolves. Quarterly updates exist because the technology and threat surface are moving faster than any annual standards body can track. AIUC-1 does not claim to replace existing frameworks like SOC 2, ISO 27001, or GDPR. It builds on them and adds the governance layer those frameworks were not designed to address. 

Closing 

AIUC-1 is the most operationally grounded standard the industry has produced for AI agents. The Q2 2026 update moves it meaningfully forward on identity and permissions, which is the foundational layer that every other access control depends on. The controls for agent identity governance (A003.3) and just-in-time permissions (A003.4) combined with existing controls on data access (A003), tool access (D003), and runtime enforcement (B006) give security teams a structured framework to answer the questions their boards and auditors are already asking. 

Governing agentic identities and NHIs requires a unified inventory, runtime enforcement at the moment of access, and full audit visibility across every agent regardless of where it was deployed. That is the operational problem Britive is built to solve. If you are working through how to implement these controls in your environment, happy to connect.