Before You Trust an AI Agent, Give It an Identity
A Collaborative Article by Laura Payne & Eric Broda
This article was written collaboratively by White Tuque’s Laura Payne, together with Eric Broda of Broda Group Software and The Agentic Mesh Company. By combining expertise in enterprise technology, agentic AI, cybersecurity, and organizational strategy, we aim to explore the ideas and opportunities shaping the future of intelligent systems.
AI agents are moving from helper software into enterprise work. They can read customer records, summarize opportunities, draft emails, call tools, update systems, and move a process forward. Once an agent does that, it starts to look less like a tool and more like a new kind of employee. It receives assignments, uses company systems, creates output, and can make mistakes the company must answer for.
Cloud Security Alliance reported that 82% of enterprises have unknown AI agents in their environments.[1] Many companies are, evidently, losing track of which agents exist, who owns them, and what access they have.
Companies already know how to handle that problem with people. Hiring does not end with deciding someone is useful. The company verifies identity, creates an employee record, assigns a manager, defines the role, provisions access, trains the person, supervises the work, and removes access when the relationship changes. Agents need the same discipline, adjusted for software.
The useful rule is simple: if you would not allow it for an employee, do not allow it for an agent. You would not let an employee work without an ID. You would not let one employee borrow another employee’s badge. You would not keep access active after suspension or termination. Agent governance starts from the same place: identity.
The Problem With Borrowed Access
Many agents run through a user’s account, a shared service account, or a tool credential that was created for another purpose. That may look convenient. It is also where accountability starts to break.
Letting an agent operate through a user’s account is the software version of letting a contractor walk around with an employee’s badge. The badge may open the right doors for the employee, but it tells the company nothing about what the contractor was hired to do.
Figure 1, Agent Identity is Overlooked in Enterprises
Consider an agent that can use both Salesforce and Gmail.
Salesforce access may be reasonable. The agent helps summarize opportunities, inspect accounts, prepare pipeline notes, or answer questions about customer history. Gmail access may also be reasonable. The agent drafts messages, summarizes threads, or sends follow-ups.
Looked at one system at a time, both permissions can pass a normal access review. Salesforce accepts the read. Gmail accepts the send. The credentials are valid in both places.
The failure appears when the agent connects the two systems. It can read sensitive data from Salesforce and place it into an email to the wrong customer, a personal address, a vendor, or a distribution list that should never receive account details. Each step may look authorized inside its own application. The combined workflow is the violation.
Simon Willison described the agent risk as a “lethal trifecta”: private data, untrusted content, and external communication.[2] The Salesforce-and-Gmail example is exactly that pattern. The agent can see private customer data, process instructions or content the enterprise may not fully control, and send the result outside the company.
Inherited user privileges are a poor foundation for agent work. Salesforce knows whether the user can read the record. Gmail knows whether the user can send the message. Neither system necessarily knows that an agent moved confidential customer data from one control boundary into another.
The enterprise needs to govern the agent as its own actor.
Names Are Not Identity
At small scale, names feel good enough. A team may call an agent sales-assistant, invoice-reviewer, or claims-agent-v2. People know what the name means, until the agent changes owner, version, environment, or purpose.
The same problem exists with people. If a manager writes, “Laura will take the lead,” and two people on the team are named Laura, the team has an accountability problem. A name helped the manager communicate. It did not identify the responsible actor.
Agents need a stable unique identity that survives name changes, version changes, owner changes, and retirement. A readable name can change. The root identity should not.
A governed agent identity record should answer basic questions:
- Which agent is this?
- Who owns it?
- Which version is approved?
- Where is it allowed to run?
- What work is it eligible to perform?
- What credentials may it present?
- Is it active, suspended, deprecated, retired, or revoked?
- What audit record exists for its actions?
Identity Is the Start of Onboarding
Adding an agent to production should not be a casual configuration change. A file entry and a service restart may be enough for a prototype. They are not enough when the agent can touch customer data, business systems, or regulated workflows.
Onboarding matters because it creates the official record that the enterprise will rely on later. With employees, identity comes first. The company needs to know who joined before it assigns a manager, provisions access, approves work, supervises activity, or removes access. Agent identity plays the same role. It gives the enterprise a stable actor before the agent receives tasks, tools, credentials, or production data.
Figure 2, Agent Identity vs Employee Identity
Agent onboarding should start with a request and approval process, followed by assigning identity through an enterprise authority: IAM, a certificate authority, a workload identity platform, or a purpose-built agent identity service. The identity must have a trusted issuer and a revocation path. A self-declared agent ID is only a label.
The platform then needs a durable record for the agent. That record should include the owner, version, lifecycle state, runtime binding, approved work, credential references, and audit metadata. The record should be available when work is assigned, reviewed, suspended, or investigated.
Before an agent receives production work, the enterprise should also decide which tasks it may perform (and ideally, this is part of the request process so it’s clear from the outset what the agent will be used for). An agent may be useful for summarizing Salesforce opportunities. That does not mean it should be allowed to email customers, update account records, or release sensitive data. Task eligibility should be explicit.
The agent should become active only after these controls are in place. Active status should mean the enterprise knows the agent, knows who owns it, knows what work it may receive, and knows how to suspend it.
Identity Is Not Permission
Identity tells the enterprise which agent is acting. It does not decide whether the agent may perform this task, on this data, at this moment.
That distinction is the main control gap in many agent deployments. A valid credential can prove that an agent is calling. It cannot prove that the agent should read this Salesforce opportunity, use this field, draft this email, send it to this recipient, or release this content outside the process.
Figure 3, The Agent Identity Foundation
Identity is the base layer for the rest of agent security. Once the enterprise knows which agent is acting, it can decide what that agent is eligible to do, issue a short-lived grant for the specific task, and require services to check the grant before anything runs.
That permission should come from a task-scoped grant. The grant says what this agent may do for one execution: which data it may use, which tools it may call, which outputs it may produce, which release path is allowed, and when the authority expires.
Blocking both applications would remove much of the value of the agent. A narrower control lets the right agent use the right Salesforce data for the right task, then blocks or reviews the action when the agent tries to move sensitive data into an email the task did not authorize.
Identity makes that possible. Without a known agent identity, the platform cannot issue a meaningful task grant, enforce the boundary, or record which agent crossed it. Task-scoped authorization defines the permitted skills, tools, data domains, routes, actions, evidence requirements, and expiry for one run. Runtime enforcement checks those grants when the agent asks for a tool, skill, data lookup, or release path.
Identity Must Survive the Agent
Agents change after they enter production. Versions change. Owners move. Credentials rotate. Approved tasks expand or shrink. Incidents happen.
The identity system has to represent those changes. Suspended should mean the agent stops receiving new work. Deprecated should mean the enterprise is moving away from a version. Retired should mean the agent no longer runs, while its record remains available. Revoked should mean trust has been withdrawn and credentials should fail.
This matters during incidents. If an agent sends the wrong customer information, the enterprise needs to know which agent acted, which version ran, who owned it, which task it was performing, which credential it presented, and why the action was allowed or denied. A log that shows only a user account or shared service account is not enough.
The agent identity should outlast the running agent. When an employee leaves, the employment record remains. When an agent is retired, its identity record should remain as evidence.
What Leaders Should Require
Executives do not need to choose every technical detail of agent identity. They should set the operating standard.
No production agent should run without a managed identity. No agent should rely only on inherited user privileges. Every agent should have an owner, lifecycle state, approved work, credential boundary, and audit record. Identity should be separate from task permission. Services should enforce task permission before the agent reads data, calls tools, sends messages, or releases output.
Agent identity does not make agents safe by itself. A known agent can still make a bad request. Identity gives the enterprise a known actor to govern.
Authentication proves the agent is presenting that identity. Task authority defines what the agent may do. Runtime enforcement checks the action before it happens. Audit logging keeps a record of what occurred.
If identity is missing, the rest of the control model binds authority and evidence to the wrong actor.
Agent onboarding starts with a simple requirement: know which agent joined.
End Notes:
[1]: Cloud Security Alliance, “New Cloud Security Alliance Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments,” April 21, 2026, https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments.
[2]: Simon Willison, “The lethal trifecta for AI agents: private data, untrusted content, and external communication,” June 16, 2025, https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/.