Every AI Agent Needs an Identity
A company gives an AI agent access to its shared drive, CRM platform and email system. The agent can retrieve client records, prepare proposals, update sales opportunities and send follow-up messages. It works across several applications and performs tasks that previously required an employee. Yet the company may still struggle to answer a basic question: who is acting when the agent completes the work?
Many organisations build agents as extensions of a user account, a software application or a shared service credential. This may be sufficient during a controlled pilot. It becomes dangerous once the agent starts operating independently, accessing sensitive information or initiating actions across several systems. An enterprise agent needs its own identifiable place within the organisation. The company should know what the agent is, who authorised it, which resources it can access, which actions it may perform and when its permissions should expire. Without that identity, the agent can become a capable digital actor with extensive access and weak accountability.
An Agent Is More Than Another Application
Traditional enterprise software usually follows predictable instructions. An application receives a defined input, runs a programmed process and produces an expected output. Security teams can map its connections and specify the operations it performs.
AI agents behave differently. They interpret objectives, choose intermediate steps and call tools according to the situation they encounter. A sales agent might search a CRM record, consult previous correspondence, review a pricing file, draft a proposal and ask another agent to check the terms.
The sequence may change from one task to the next. This flexibility gives agents much of their value, but it also complicates access control. A conventional application may need permission to execute a small number of predefined operations. An agent can potentially combine several legitimate permissions in ways that nobody anticipated when those permissions were granted.
The security question therefore changes. Companies must determine not only whether the agent can connect to a system, but whether it should perform a particular action, on a particular resource, for a particular purpose and under a particular person’s authority. An individual identity provides the foundation for answering those questions.
Shared Credentials Remove Accountability
The simplest way to connect an agent to enterprise systems is often to give it an existing service account or allow it to act through the credentials of an employee.
Both approaches create problems. When several agents use the same service account, activity logs may show that the account opened a document or changed a record without revealing which agent performed the action. Investigators can see that something happened but may not be able to reconstruct the responsible workflow.
Allowing an agent to inherit an employee’s identity creates a different ambiguity. The system may record the employee as the actor even when the agent selected and executed the action independently.
This matters when an agent sends an incorrect payment instruction, changes a client record or discloses confidential information. The company needs to establish whether the employee requested the action, whether the agent exceeded the request and which system allowed it to proceed.
An agent-specific identity creates a clearer audit trail. It allows the organisation to distinguish between human decisions, delegated actions and autonomous steps taken within an approved workflow.
That separation supports incident investigation, compliance reviews and ordinary operational oversight. It also prevents the company from treating every agent error as though the sponsoring employee personally performed it.
Every Agent Needs an Accountable Sponsor
Giving an agent a technical identity does not make it accountable. The organisation also needs a named human owner.
An agent may perform work across several departments, but someone must remain responsible for its purpose, permissions and continued operation. This sponsor should understand what the agent does, which data it uses and what could happen if it acts incorrectly.
The sponsor does not need to approve every routine action. Constant approval would remove much of the value of automation. The sponsor should instead own the boundaries within which the agent operates.
That includes requesting access, reviewing unusual permissions, confirming that the agent still serves a legitimate business purpose and deciding when the organisation should suspend or retire it.
Ownership should not remain informal. A pilot created by one employee can gradually become part of a critical process, even after that employee changes role or leaves the company. The agent may continue to hold credentials and execute tasks without an active business owner.
Companies already face this problem with abandoned applications and service accounts. Agents can make it more serious because they do not merely retain access. They can continue to use it.
Permissions Should Follow the Task
An agent should not receive all the access available to its sponsor.
A manager may be able to view compensation data, approve expenditure and read confidential board documents. An agent that arranges meetings on the manager’s behalf does not need the same authority.
Companies should grant permissions according to the agent’s defined function. A scheduling agent may need access to calendar availability but not the full contents of every meeting. A procurement agent may compare supplier quotations without receiving permission to approve a contract. A support agent may retrieve account information while remaining unable to change payment details.
This is the principle of least privilege applied to agentic systems. The agent receives only the access required to complete its authorised task.
The principle sounds familiar, but agents make it harder to enforce. Developers may add tools as a project expands, departments may connect new data sources and users may request broader functionality. The agent gradually accumulates permissions that no longer correspond to its original purpose.
Security teams should therefore treat permission reviews as a continuing process rather than a one-time deployment check.
They should also distinguish between reading information and taking action. Allowing an agent to inspect an invoice is different from allowing it to change the bank account attached to that invoice. Reading a draft contract is different from sending it to the counterparty.
The most consequential actions may require an additional control, such as human approval, stronger authentication or confirmation through a separate system.
Delegation Must Be Visible
Many agents do not act entirely on their own authority. They perform work delegated by a user.
The identity system should preserve that relationship.
A record should show that a particular employee instructed a particular agent to perform a defined task. The system should then distinguish between actions covered by that instruction and additional steps the agent chose during execution.
This matters because delegation is not unlimited consent.
An employee may ask an agent to prepare a list of overdue invoices. That request does not necessarily authorise the agent to contact clients, change payment terms or initiate collection procedures. The agent’s ability to infer a useful next step should not automatically give it permission to take that step.
Clear delegation controls allow companies to combine autonomy with defined authority. The agent can decide how to complete an approved task while remaining unable to expand the task beyond its permitted scope.
Delegation should also have a time limit. An agent that receives temporary access to complete a project should lose that access when the project ends. Temporary authority should not become a permanent credential simply because nobody remembered to remove it.
Identity Makes Monitoring More Useful
Companies cannot govern agents they cannot distinguish.
An inventory should record every deployed agent, its sponsor, its function, its connected systems and the permissions assigned to it. The organisation should also know whether the agent is active, experimental, suspended or scheduled for retirement.
This creates a basis for meaningful monitoring.
Security teams can identify unusual activity when they understand an agent’s normal role. A research agent that suddenly attempts to modify payroll data presents an obvious mismatch. A customer-service agent that exports an unusually large volume of records may require immediate investigation.
The organisation can also compare similar agents and identify duplication. Several departments may have created separate tools that perform almost the same task while accessing the same data through different controls.
Without an identity inventory, those agents can spread faster than the governance structure surrounding them. Each new agent becomes another non-human actor that can access systems, hold credentials and create operational dependencies.
Visibility should begin during development, not after deployment. Low-code platforms make it possible for business teams to create agents without waiting for a central software project. That speed can be useful, but the resulting agent should still enter the company’s identity and approval process before it receives production access.
Agents Need a Lifecycle
Employees join, change roles and leave. Their access rights should change with them.
Agents need an equivalent lifecycle.
A company should establish how an agent receives its identity, who approves its initial permissions and when those permissions are reviewed. It should also define what happens when the sponsoring employee leaves, the underlying process changes or the agent is replaced by a newer version.
An updated agent may require a new assessment even when it retains the same name. A different model, tool connection or instruction set can alter how it behaves and which risks it creates.
Retirement deserves particular attention. Disabling the visible interface may not remove API keys, background processes, scheduled tasks or connections to other agents. The organisation must revoke credentials, close access paths and preserve the records needed for audit or investigation.
Dormant agents should not remain operational indefinitely. An agent that has not performed a legitimate task for a defined period may need to lose its access automatically until the owner confirms that it is still required.
Human Approval Cannot Solve Everything
Companies often respond to agent risk by placing a person at the end of the workflow. The agent prepares the action, and the employee clicks approve.
This control can help, especially for payments, contracts, external communications and changes to sensitive records. It is not sufficient on its own.
Employees may approve requests quickly because the agent usually produces acceptable work. They may not understand which data the agent accessed, how it reached its conclusion or whether an apparently routine request contains an unusual step.
Approval also becomes weaker when agents generate a large volume of decisions. A human reviewer who receives hundreds of low-context requests may provide little more than ceremonial oversight.
Identity and access controls reduce the burden on human reviewers by preventing the agent from proposing or executing actions outside its authorised role. Human approval can then focus on genuinely consequential decisions instead of compensating for an excessively broad permission model.
The strongest design combines both. The agent has a defined identity, limited authority and a complete activity record. Human intervention applies where the potential impact justifies it.
Identity Is the Starting Point for Enterprise Agents
Companies often evaluate AI agents according to what they can accomplish. They compare model performance, integration options and the amount of work the system can automate.
Production deployment requires another question: under whose authority does the agent act?
A reliable answer requires more than a name displayed in a dashboard. The agent needs a distinct technical identity, an accountable sponsor, task-specific permissions, visible delegation and a managed lifecycle. Its actions must remain attributable even when it collaborates with other agents or works across several enterprise systems.
These controls do not eliminate the risks created by autonomous software. They make those risks governable.
An agent without an identity can accumulate access, perform actions and create dependencies while remaining difficult to trace or remove. An agent with a clearly managed identity becomes a recognised enterprise actor whose authority the organisation can inspect, limit and revoke.
As companies deploy more agents, identity will no longer sit at the edge of the implementation. It will determine whether the organisation can expand autonomy without losing control.
