AI GOVERNANCE
AI agent identity is now a company-control problem
AI agent identity has moved from a model-security topic to a company-control issue: teams need verifiable legal-entity authority, scoped access and evidence.
The new control is authority, not just authentication
AI agent identity became an implementation issue this week because verifiable organizational identity is now being applied directly to agents that speak, transact or make requests on behalf of companies. GLEIF’s 25 August 2026 analysis argues that the fixed point is not the model itself, which may change, but the legal entity responsible for the agent and the authority under which the agent acts. That makes AI agent identity a KYB, risk and audit problem as much as an engineering problem.
- Decision: treat agent launch as an identity-control event, not only a model-release event.
- Risk: credentials can outlive the business facts that made them trustworthy.
- Minimum evidence: entity identifier, issuer, role, scope, approval, revocation path and action log.
- Review trigger: any new tool, payment route, customer-contact channel or external data write.
The hard question is no longer, “Can this system log in?” It is, “Can another party verify that this agent really represents the named company, that the company still exists, and that the agent was allowed to perform this action?” For product and compliance teams, that shifts design away from generic bot labels and toward evidence that links agent, entity, role, scope and timestamp.
GLEIF points to the LEI as the organizational anchor and vLEI as the digital counterpart that can allow computational verification of legal-entity identity, authority and role. The important word is “authority.” A service account may prove that software has a credential, but it does not by itself prove that a legal entity has delegated a specific business authority to that software.
CompanyProof’s view is that this is the same stale-fact problem teams already face with directors, ownership, filed accounts and registry status. An agent credential that was accurate at issuance can become misleading if the company changes, the role is revoked, the tool scope expands or the counterparty cannot reconstruct the evidence chain later.
Why the last two weeks matter
The current signal is not one binding rule that solves agent identity. It is a cluster of standards and governance activity that narrows the responsible implementation path. NIST’s AI Agent Standards Initiative, updated on 14 August 2026, describes work on industry-led standards, community-led protocols and research into agent authentication and identity infrastructure for secure human-agent and multi-agent interactions.
- NIST: identity infrastructure is a standards pillar for agentic systems.
- OpenID: interoperability tests are focused on enterprise resources and cross-organization access.
- OWASP: tool and permission changes should refresh threat models.
- GLEIF: legal-entity anchoring is available now through LEI and vLEI concepts.
OpenID’s interoperability effort adds a near-term implementation calendar. Its call for participation focuses on two scenarios: agent governance, meaning only authorized agents reach enterprise resources, and cross-organizational identity assurance, meaning agents from one organization can access MCP servers in another. Participants were asked to commit by 10 August 2026 and show at least one successful partner test by 16 October 2026.
OWASP’s recent agentic security material sharpens the operational point. Its threat-modeling guidance says agentic components can gain new authority, trusted inputs or external effects without an obvious architecture change. It recommends capability manifests, IAM-like review gates and build checks when permissions or tool registries change.
Together, these materials make a practical statement: identity for agents will be judged at boundaries. Internal demos can rely on local conventions. Production agents that call suppliers, customers, payment systems, registries or data processors need identity artifacts and logs that another organization can verify without trusting a chat transcript.
Build the agent record like a company record
A useful AI agent identity record should look less like an API key inventory and more like a lightweight company-control record. It should answer who the responsible legal entity is, how that entity was verified, which human or role approved the agent, what the agent may do, which systems can rely on it, and when each fact was last checked.
- Entity: legal name, jurisdiction, registration number and LEI or other stable identifier where available.
- Authority: approving role, delegation basis, permitted actions and prohibited actions.
- Credential: mechanism, issuer, expiry, rotation policy and revocation endpoint.
- Evidence: registry checks, ownership or director checks, release approval and runtime logs.
CSA’s July 2026 work on non-human identity is helpful because it separates the identity subject from the credential. An AI agent is not merely the secret, token or certificate it uses. It is the non-human principal that can authenticate and be authorized to access resources, often through software lifecycle events rather than HR lifecycle events.
That distinction matters for stale-fact monitoring. Tokens rotate, but a stale authority can remain hidden if the system only checks whether the token is valid. A director may leave, a regulated subsidiary may be renamed, an agent may be moved to a new workflow, or a tool may gain write access that was not contemplated when the original risk review passed.
Teams should maintain an agent record that is versioned with product releases and connected to source-of-truth company evidence. For a customer-facing or counterparty-facing agent, the record should be inspectable enough to support complaints, incident reviews, regulator questions and contractual disputes. For an internal agent, the same pattern supports access recertification and privilege reduction.
Do not confuse disclosure with verifiable authority
The EU AI Act Service Desk makes an important distinction for governance teams: AI agents are not a separate legal category under the AI Act, but rules for AI systems and GPAI models can apply to them. It also states that from 2 August 2026, transparency rules apply when an AI agent is intended to interact with natural persons or generate content. That is a disclosure requirement, not a complete identity architecture.
- Disclosure answers: is this interaction with AI?
- Organizational identity answers: which legal entity stands behind it?
- Authorization answers: may this agent perform this action now?
- Audit evidence answers: can we prove that later?
A customer-facing notice that says “you are speaking with an AI agent” may satisfy one class of transparency need, but it does not prove which company operates the agent or which actions the agent may take. A support agent that can change addresses, issue refunds or collect documents needs a stronger authority trail than a content-only assistant. A procurement agent that negotiates with suppliers needs counterparty-verifiable identity, not just an internal label.
This is where KYB and AI governance start to overlap. If an agent asks a bank, marketplace, processor or supplier to accept instructions, the receiving party needs to know whether the sender is a recognized entity, whether the entity is still active, and whether the agent’s delegated authority covers the requested action. Those are company-data questions expressed through an agent interface.
The immediate implementation decision is to separate user transparency, organizational verification and transaction authorization. They support each other, but they are not substitutes. A banner tells a person they are interacting with software; an organizational credential ties the software to a legal entity; an authorization policy decides whether the requested action is allowed.
The threat model must follow capability drift
Agent risk rises when capability changes faster than review. OWASP’s AI threat-modeling guidance is explicit that agentic components can gain authority through tools, delegated permissions, instructions, memory, orchestration or external effects. A feature may look unchanged in the architecture diagram while the agent has quietly gained the ability to send emails, update customer records or call a payment API.
- Gate manifest changes outside the feature team.
- Fail release checks when authority changes without review.
- Make sub-agents verify scope instead of trusting the orchestrator blindly.
- Log actions at the company, agent, credential and tool-call levels.
OWASP’s Cornucopia agentic AI card on compromised orchestration shows why the control plane matters. If downstream agents treat orchestrator instructions as unconditional, one compromised control layer can dispatch attacker-defined workflows at scale. OWASP’s mitigations include hardening the orchestration API, signing workflow definitions, requiring sub-agents to validate scope independently and limiting egress.
For product teams, the practical artifact is a capability manifest. It should list every tool an agent can call, whether the call is read-only or has an external effect, what approval gate applies, and which evidence is captured. The manifest must be reviewed like an IAM policy because it is an IAM policy in product clothing.
For compliance and risk teams, the key is to demand evidence before an incident. Logs should connect the company identity, agent identity, human approver, model or agent version, tool call, input class, policy decision and output action. CompanyProof can fit into this control design as a place where verified company facts are checked and rechecked before they are relied on by an agent workflow.
A 30-day implementation plan for risk and product teams
The best first step is not a platform migration. It is an inventory that joins non-human identity governance with verified company facts. List every agent or agent-like workflow that can act without a human typing each instruction, then classify whether it reads data, writes records, contacts people, transfers value, changes security posture or instructs other agents.
- Week 1: inventory agents, tools, identities and external effects.
- Week 2: map each agent to legal entity, owner, approver and relying parties.
- Week 3: create capability manifests and review gates for authority changes.
- Week 4: test revocation, evidence retrieval and stale-fact alerts.
Next, choose where legal-entity verification is required. Internal development agents may need strong workload identity and short-lived credentials but not a public organizational credential. Agents that interact with customers, suppliers, regulated counterparties or financial flows should be designed for counterparty verification from the start.
Then bind deployment evidence to runtime evidence. A launch approval is useful only if it can be connected to what the agent actually did later. The same record should support access reviews, incident triage, complaints, vendor due diligence and regulatory questions without forcing teams to reconstruct context from chat logs and disconnected IAM exports.
Finally, set a stale-fact cadence. Recheck the company record, the approving role, the credential issuer, the tool manifest and the revocation status on a schedule and whenever a risk trigger fires. The trigger list should include new tools, new jurisdictions, new customer-facing channels, new payment capability, model-provider change, orchestrator change and any company-record change that affects authority.
Timeline: agent identity moved into implementation
Recent public signals show standards, legal and security work converging on identity, authority and evidence for agentic systems.
NIST’s AI Agent Standards Initiative lists agent authentication and identity infrastructure as part of its research work.
OWASP Cornucopia’s agentic AI card highlights orchestration compromise, independent sub-agent validation and workflow signing.
GLEIF argues that agents need verifiable organizational identity anchored to the legal entity and delegated authority.
OpenID’s MCP-based AI agent security test asks participants to show at least one successful partner test by this date.
Comparison: four controls often collapsed into one
AI agent governance fails when teams treat transparency, identity, authorization and audit evidence as interchangeable.
Tells a person they are interacting with AI or AI-generated content; it does not prove organizational authority.
Connects the agent or actor to a verified legal entity, potentially through LEI or vLEI.
Determines whether the agent is allowed to perform a specific action with a specific tool at that time.
Links approval, credential, manifest, policy decision and runtime action for review or investigation.
Process: minimum agent identity control loop
A practical sequence for deploying company-backed agents without relying on stale authority or unreviewed tool drift.
Confirm the responsible legal entity and stable identifiers before external reliance.
Record who approved the agent, what it can do and which actions are prohibited.
Version tools and external effects, and require review when permissions or workflows change.
Monitor company facts, credential status, role changes and tool expansion; test revocation before launch.
Comparison: agent risk triggers that deserve review
These are the changes most likely to make an apparently unchanged agent materially different from a control perspective.
A new API, plugin, MCP server or command can turn advisory output into action.
A credential may remain valid even when the business role or delegation basis has changed.
A compromised or over-privileged orchestrator can direct many downstream agents at once.
Agents that interact with natural persons may trigger transparency duties and higher evidence expectations.
FREQUENTLY ASKED QUESTIONS
Ten practical answers.
Direct answers to the questions implementation teams are most likely to ask.
01What is AI agent identity?
AI agent identity is the set of records and credentials that let a system prove which agent is acting, which legal entity is responsible for it, what role or authority it has, and whether that authority is still valid. It is broader than an API key because it includes entity verification, delegated authority, lifecycle controls and audit evidence.
02Why is legal-entity identity relevant to an AI agent?
When an agent interacts with customers, suppliers, payment systems or another organization’s systems, the relying party needs to know which company stands behind the action. GLEIF argues that LEI and vLEI can provide an organizational anchor for verifying the legal entity and delegated authority behind a person or system.
03Does the EU AI Act define AI agents separately?
No. The AI Act Service Desk says AI agents are not a separate category under the AI Act, but the definitions of AI systems and GPAI models are sufficient to cover many agents. Depending on use, rules for AI systems, GPAI models, transparency and high-risk systems may apply.
04What changed on 2 August 2026?
From 2 August 2026, the AI Act transparency rules apply when an AI agent is intended to interact with natural persons or generate content. That means teams should separate transparency notices from deeper controls that prove organizational identity, delegated authority and permitted actions.
05Is vLEI required for AI agent governance?
Not as a universal legal requirement. vLEI is one credible mechanism for verifiable organizational identity because it links a legal entity, role and credential through the Global LEI System. Teams should decide whether vLEI, another verifiable credential approach or internal identity infrastructure fits the risk of the agent’s use case.
06How should teams treat AI agents in IAM?
Treat them as non-human identities with explicit owners, scopes, credentials, lifecycle events and revocation paths. CSA stresses that non-human identities are created through software and infrastructure events, not ordinary HR processes, so standard employee lifecycle controls are not enough.
07What is a capability manifest?
A capability manifest is a versioned list of what an agent can actually do: tools, APIs, commands, data writes, external messages and other effects. OWASP recommends keeping this separate from architecture diagrams and gating changes to it like IAM permission changes.
08Why is orchestration a special risk?
In multi-agent systems, the orchestrator can become a privileged control plane. OWASP warns that if downstream agents trust orchestrator commands unconditionally, a compromised orchestrator can dispatch attacker-defined workflows at scale. Sub-agents should validate scope independently.
09What evidence should be retained for an agent action?
At minimum, retain the responsible legal entity, agent identifier, credential or issuer, approving owner or role, capability manifest version, policy decision, tool call, timestamp, output action and revocation status. The goal is to reconstruct why the action was allowed at the time it occurred.
10Where should a team start if it has many existing agents?
Start with an inventory and rank agents by external effect. Prioritize agents that contact customers, write company records, access regulated data, move money, instruct other agents or cross organizational boundaries. Then add ownership, scoped authority, review gates, logging and stale-fact checks before expanding capability.