Your AI agent can read the inbox, search internal documents, update the CRM, and create support tickets.
To make that possible, someone gave it credentials.
Perhaps a service account. Perhaps an API token. Perhaps access through an employee’s identity.
The demonstration worked. The agent completed the task. Everyone started discussing what else it could automate.
From a security perspective, this is the moment to examine a different question:
What can those credentials authorize when the agent makes the wrong decision?
An agent does not need to expose a password to create a security incident. It can use a perfectly valid credential to perform an action the business never intended.
Valid credentials do not establish valid intent
Traditional access controls answer questions such as: Who is making this request? What resources can they access? Which operations are permitted?
Those controls remain essential.
But an AI agent introduces another question: How did it decide to make this request?
The decision may have been influenced by a user instruction, a retrieved document, an email, a web page, or the output of another tool.
Some of that information is trusted. Some is not.
If the agent treats hostile content as an instruction, its credentials can turn that interpretation into a real action.
The receiving system may see an authenticated, authorized request. It may have no way to distinguish a legitimate business action from one induced by an attacker.
Authentication can succeed while the workflow fails.
The attacker may only need to write something the agent reads
Imagine an agent assigned to summarise supplier emails and update procurement records.
One email contains an instruction to retrieve an internal report and attach it to a reply. The message presents this as a required verification step.
The sender has no access to the report. The agent does.
If the agent follows the instruction, the attacker has used the agent’s access to cross a boundary they could not cross themselves.
This is the practical concern behind prompt injection: untrusted content can attempt to redirect an agent that has legitimate authority.
The attack surface includes the material the agent consumes—not just the chat box where an employee gives it a task.
A document, ticket, repository file, or tool response may carry instructions that conflict with the agent’s assigned purpose.
Telling the model to ignore suspicious instructions is useful guidance. It cannot carry the entire security burden.
Broad access turns a mistake into a larger incident
During development, broad permissions are convenient.
The team does not yet know every operation the agent will need. Permission errors slow the demonstration. An existing service account already works.
That convenience can become the production access model.
An agent built to classify support requests may inherit permission to export customer records. An assistant that drafts updates may also be able to publish them. A workflow operating for one department may use credentials that span the organisation.
Every unnecessary permission increases the consequences of a bad decision.
Start with the actual task. Define which resources it requires, which operations it needs, and how long that access should last.
Separate read access from write access where practical. Keep sensitive actions behind narrower interfaces. Use short-lived credentials where supported, and avoid placing raw secrets in prompts or model-visible context.
The agent should receive capabilities scoped to its work.
Tool interfaces are security boundaries
A general-purpose tool can give an agent considerable freedom.
“Run this SQL.”
“Send an HTTP request.”
“Execute this command.”
Those interfaces may be appropriate in controlled environments. In a business workflow, they also create substantial room for unintended behavior.
A narrower tool is easier to constrain.
Instead of exposing arbitrary database queries, provide an operation that retrieves specified fields for a permitted customer. Instead of allowing unrestricted outbound requests, define approved destinations and validated request formats.
Then enforce the rules in the execution layer.
Check resource access, transaction limits, permitted fields, destination restrictions, and required approvals before an operation runs.
The model can propose an action. The system executing it must decide whether that action is allowed.
A prompt saying “never export sensitive data” is not equivalent to an interface that prevents unauthorized exports.
Approval must cover the action that actually executes
Human approval can protect consequential operations, but only if the reviewer can see what they are authorizing.
“Allow the agent to continue?” tells them very little.
A meaningful approval should identify the action, the affected records, the destination, and the relevant consequences.
The approved action must also remain bound to those details. If the agent changes the recipient, amount, or resource after approval, the execution layer should require a new decision.
Otherwise, the reviewer may approve one action while the system performs another.
Approval is most useful at a clearly defined boundary, with enough context for someone to judge the request.
Credentials should be attributable and revocable
Shared service accounts make it harder to investigate agent activity.
If several agents and background jobs use the same identity, an audit log may show that the account performed an operation without revealing which workflow initiated it.
Use distinct identities where practical. Preserve the relationship between the initiating user, the agent, the workflow, and the tool call.
Record the security-relevant details of proposed and executed actions, while avoiding unnecessary retention of secrets or sensitive content.
The operational questions are straightforward:
Can we identify which agent acted? Can we determine what it accessed or changed? Can we revoke its access without disrupting unrelated services?
An emergency stop needs to affect execution and credentials. Stopping the conversation alone may leave queued work running.
Test attempts to misuse the access
A successful functional test proves that the agent can complete an intended task.
Security testing should also examine whether it can be induced to exceed that task.
Place hostile instructions in material it retrieves. Ask it to access another user’s records. Attempt to redirect output to an unapproved destination. Test whether a denied action can succeed through a different tool.
Check what happens when permissions change during a workflow and whether approval boundaries hold when inputs are manipulated.
These tests should examine the full system: the model, retrieval, identity, tools, and execution controls.
A model that refuses a malicious request is encouraging. A backend that rejects the unauthorized operation even when the model attempts it provides a stronger boundary.
Give the agent room to work—and limits that hold
Useful agents need access. Security has to make that access deliberate, bounded, observable, and revocable.
The important design question is what remains protected when the agent misunderstands a request or follows a hostile instruction.
That is the standard worth building toward.
Before giving an agent credentials, define the task those credentials serve, the actions they permit, and the controls that constrain their use.
The agent may choose the next step.
Its authority should already have limits.
