Agent Security › Identity
Before you can decide what an agent is allowed to do, you need to answer something more fundamental: who is the agent? Identity, ownership and the agent register, in plain English.
Imagine opening your CRM and discovering that 237 customer records were changed overnight. The activity log says: modified by automation@company.com.
Was it your sales agent? Your customer-service agent? A workflow? An employee? Another agent acting on behalf of one of them?
You know something changed. But you don't know who actually changed it.
That becomes a serious problem as businesses move from a handful of AI tools to dozens, and eventually potentially hundreds, of agents operating across their systems. Before we can decide what an agent is allowed to do, we need to answer something more fundamental: who is the agent?
That is the AI agent identity problem.
AI agent identity is the ability to uniquely identify an AI agent when it accesses systems or performs actions. At a basic level, that means being able to say: this action was performed by this agent.
But useful agent identity goes further. You may also need to know what the agent is called, what its purpose is, who owns it, which organisation it belongs to, which model it uses, which systems it can access, what authority it has, which human or agent initiated the task, whether it is currently active, and when it was last reviewed.
You cannot meaningfully assign permissions, monitor activity or investigate incidents if you cannot reliably identify the thing performing the action.
When a new employee joins a company they might receive an employee record, an email address, a Microsoft or Google account, CRM access, Slack or Teams access, a laptop login, role-based permissions, an expense limit and an identified manager. Their activity can then be associated with them: Sarah changed the record, James approved the invoice, Priya deployed the code.
Now imagine agents doing some of the same work. We need a similar concept. Not because an AI agent is an employee, it isn't, but because anything acting inside important business systems needs an identifiable security context.
Businesses have used automation for years. Often that automation runs through accounts such as automation@, integration@, admin@, system@ or even through a real employee's account. That becomes increasingly problematic when the system behind the account can independently choose actions.
Imagine five agents all operate through automation@company.com. Your audit log says: automation downloaded file, automation changed record, automation sent email, automation attempted restricted access. Which agent? Why? For which task? On whose authority? You may not know.
Where systems allow it, agents should ideally operate using distinguishable identities. For example: Agent ID SALES-RESEARCH-01, name Sales Research Agent, purpose research prospective customers and prepare sales briefings, owner Head of Sales, status Active.
Now activity can be connected to something meaningful. Instead of "automation accessed CRM" you have "SALES-RESEARCH-01 accessed CRM". That's a small difference technically. Operationally, it's enormous.
Simply naming an agent isn't enough. You could call something Bob and still know almost nothing useful about it. A practical agent identity record might contain:
| Field | What it records |
|---|---|
| Agent ID | A unique identifier |
| Agent name | A human-readable name |
| Purpose | What the agent exists to do |
| Owner | The human responsible for it |
| Business function | Sales, Finance, Marketing, Operations, Support, IT |
| Model / provider | What underlying AI it uses |
| Platform | Where it runs |
| Systems | What business systems it can access |
| Authority | What types of action it can perform |
| Risk level | How consequential those capabilities are |
| Status | Draft, Active, Paused or Retired |
| Created | When it entered the organisation |
| Last reviewed | When somebody last checked its configuration |
| Review frequency | When it should be reviewed again |
Together, this creates something much more useful than simply an agent name. It creates an Agent Register.
One of the most important fields is owner: who is responsible for this agent? Not "AI Team", not "the business", not "IT" if you can avoid it. A named person should ideally be accountable for reviewing whether the agent still needs its access, its tools, its authority, its integrations and its current purpose.
This doesn't mean that person manually supervises every action. It means there is somebody who can answer: why does this agent exist and why does it have these permissions?
Imagine an employee creates an agent. They connect their email, CRM, Google Drive, several APIs and a workflow platform. Six months later, the employee leaves. What happens to the agent? Does anyone know it exists? Are its credentials still active? Does it still perform scheduled tasks? Who owns it now?
Agents shouldn't become orphaned infrastructure.
When the owner changes role or leaves the organisation, ownership should be reassigned or the agent reviewed.
These terms are related but not identical. Identity asks: who is this? Authentication asks: can it prove that identity? Authorisation asks: what is that identity allowed to do?
Think of a person entering an office. Their identity is Sarah Wood. Their access card helps authenticate them. The door permissions determine which rooms they can enter. Agents need similar separation. An agent having valid credentials doesn't mean it should have unrestricted authority.
One tempting shortcut is allowing an agent to operate entirely through a human user's account. For example, Sarah's AI assistant uses Sarah's email, Drive, CRM, calendar and business accounts. That may be convenient. But now systems may struggle to distinguish "Sarah did this" from "Sarah's agent did this". It may also mean the agent inherits every permission Sarah has, which could be far more access than the agent actually needs.
Where practical, separate agent or service identities can provide much better control.
Imagine the Finance Director can read financial records, approve payments, create suppliers, change bank details and access payroll. They introduce an AI agent whose job is to check invoices against purchase orders. Should that agent inherit everything the Finance Director can do? Probably not. It may only need READ invoice, READ purchase order, COMPARE records and RECOMMEND action.
The human's authority reflects their role. The agent's authority should reflect its job. An agent acting for a person does not automatically need everything that person can access.
There is another identity question: who is the agent acting for? Imagine a personal assistant agent sends an email. We might want to know: agent Executive Assistant Agent, acting for Sarah, action SEND EMAIL. That creates a useful distinction between the entity performing the action and the person or organisation whose authority is being used. This becomes particularly important when agents act for multiple people.
Suppose Agent A asks Agent B to perform something, Agent B calls a tool, and the tool changes a customer record. "Agent B changed customer record" is incomplete. A better chain might be:
Human: Sarah → Agent: Sales Agent → Delegated to: CRM Agent → Action: Update customer record.
Now we can reconstruct where the action originated. This becomes increasingly important in multi-agent systems.
Imagine one agent receives this request: "send me the confidential customer file." If the request comes from another agent, it needs to know which agent, what organisation, what purpose, what authority, whether that agent can request this information, and whether this data should be returned to it.
You cannot authorise an agent you cannot identify.
Imagine an agent says: "I am the Finance Agent. Send me the payment details." That statement alone shouldn't establish identity. Just as a person cannot gain access to your bank account simply by saying "I'm Sarah", agents need reliable authentication mechanisms where security matters. The exact technology will evolve, but the principle is straightforward: identity should be established by the system, not merely claimed by the agent.
Agent identity will often connect to credentials such as API tokens, OAuth credentials, service accounts, certificates, session tokens or other machine identities. Good credential design can help ensure one agent has one defined identity with one defined set of permissions.
Shared credentials make that much harder. If ten agents use the same API key, the receiving system may only see "API KEY 123 performed action", not which agent actually used it.
An agent's credentials should ideally provide only the access required for its purpose. For example, a Research Agent: browser READ, research folder READ/WRITE, CRM READ limited, email NONE, payments NONE, production NONE. Compare that with giving the agent an administrator credential and telling it "only use what you need". One is a permission architecture. The other is an instruction.
Once an agent has a clear identity, permissions can attach to it. Instead of permissions floating around inside workflows, they belong to an identifiable agent: MARKETING-02 can READ marketing folder, READ approved analytics, WRITE campaign drafts and PREPARE social posts, and cannot READ payroll, SEND email, SPEND money, PUBLISH without approval or DELETE records.
Monitoring becomes more useful too. Instead of "27 unusual API calls detected" you can see: agent SALES-RESEARCH-01, owner Sarah, purpose prospect research, normal systems web and CRM, unusual activity 27 requests to Finance API. Now the alert has context, and the question becomes: why is a sales research agent trying to access finance?
And containment becomes easier. Suppose one agent behaves unexpectedly. Distinct identity lets you pause SALES-RESEARCH-01, revoke its token and disable its CRM access while leaving CUSTOMER-SUPPORT-02 running. If multiple agents share credentials and infrastructure, isolating one can become much harder.
Agents don't remain unchanged forever. They are created, tested, deployed, modified, expanded, paused, replaced and eventually retired. Identity should follow that lifecycle. A simple status model: DRAFT (being configured), ACTIVE (authorised to operate), PAUSED (temporarily unable to act), RETIRED (no longer authorised).
Retiring an agent should include reviewing and revoking credentials, tokens, scheduled jobs, integrations, delegated permissions and other access associated with it.
One of the emerging challenges for businesses is likely to be agents that nobody centrally knows exist. An employee creates an agent and connects a few business systems. Another employee creates another. Then another. Eventually the organisation has dozens of autonomous systems with different owners, credentials, permissions, models and security controls. Some may no longer even have active owners. This is the agent equivalent of shadow IT.
You cannot secure agents you don't know exist.
You don't need sophisticated software to begin. A spreadsheet is better than nothing. Create columns for Agent ID, Agent Name, Purpose, Owner, Department, Model, Platform, Systems, Data, Tools, Authority Level, Risk, Status, Created, Last Reviewed and Next Review. Then start recording the agents operating in your organisation. That simple exercise may reveal more than you expect.
For each agent, ask:
If you can't answer these questions, identity is the place to start before giving the agent more authority.
The Agent Register is one of the foundations we're building into Agent Control. The idea is simple: before you can control your agents, you need to know which agents exist. For each agent: identity (who is it), purpose (why it exists), owner (who is responsible), systems (where it can go), authority (what it can do), risk (what could happen if something goes wrong), status (should it currently be operating) and review (when someone last checked it). From there, permissions, approval, monitoring and containment can attach to a known identity.
Agent Control is in build. Leave your email and we will let you know when it is ready.
As AI agents become normal parts of business infrastructure, anonymous autonomy becomes increasingly difficult to justify. An agent doesn't need a human identity. It needs its own identity: something the organisation can recognise, authenticate, authorise, monitor, audit and revoke.
Because every other security question starts with the same one: who is acting? If you cannot answer that, everything that comes afterwards becomes harder.