Your AI agent is another user

An AI agent that can read email, update your CRM or trigger a payment needs its own identity, limited permissions and a person responsible for switching it off. Calling it AI does not change what those permissions allow.

The quickest way to get an agent working is to hand it a key to the systems it needs. An enquiries agent gets access to a shared mailbox, a CRM token and permission to draft replies. Someone uses an administrator token because the narrower role is not ready yet. The demo works, everyone moves on, and two months later that temporary token is still there. Nobody can say which customer records the agent touched.

We would not onboard a staff member that way. The model should not get a pass because it works through an API.

A chatbot gives you an answer to review. An agent can take the next step itself because somebody connected it to email, files, customer records or finance software. Once that happens, the model is only part of the security picture. The account decides what it can reach, and the workflow decides what it can change.

The agentic AI security guidance published by ASD's Australian Cyber Security Centre and its international partners makes the same point in more technical language. It recommends a distinct identity for each agent, the minimum permissions required for its approved job, human approval at decision points and continuous monitoring of what the agent does. The guidance was written for large organisations and infrastructure, but those controls make just as much sense for a business with ten people connecting an agent to Outlook and HubSpot.

Start by asking whether you need an agent

An agent is useful when the next action depends on context that fixed rules cannot handle cleanly. It may need to read an enquiry, work out which service it concerns, find the matching customer record and prepare a response. That is different from copying every new form submission into a spreadsheet, which ordinary automation can do with fewer moving parts.

The government guidance makes an unfashionable point before it gets into security controls. A business should consider whether it can simplify or remove a repetitive process before adding an agent to it. We agree. If a fixed workflow can do the job, use the fixed workflow.

When an agent is justified, the access plan belongs in the design from the start. It should not arrive as a security clean up after the demo.

The prompt is not the boundary

People spend a lot of time tightening the instruction given to an agent. That instruction matters, but it does not reduce the permissions on the credential underneath it.

An enquiries agent may be told to update only the lead record attached to the current email. If its CRM token can export every contact, change record owners and delete deals, all of those actions remain available. A good prompt asks the model to stay in its lane. The account decides whether a mistake can leave it.

This becomes more important when the agent reads material from outside the business. An incoming email is data to a person, but it is also text that a model may interpret as an instruction. Microsoft's current guidance on prompt injection in email says the malicious instruction may sit in the subject, body, quoted replies, an attachment or hidden markup. An assistant that summarises or replies to the message may follow the attacker's instruction instead of yours.

Filtering and prompt design can reduce that risk. They cannot turn an administrator token into a sensible security boundary. If the agent follows the wrong instruction, limited permissions decide how far it gets.

Give the agent its own identity

Every platform names this differently. An agent may use a dedicated agent identity, a service principal, a service account or delegated access from a person. The useful rule is that you must be able to identify it separately from the employee who created it.

Microsoft Entra now treats an agent identity as the primary account an agent uses to authenticate. It receives its own identifier and may record a human sponsor who is accountable for the agent. Some Microsoft services still require an optional user account as well, which is why the title of this article is a mental model rather than a claim that every platform stores agents as ordinary users.

The distinction matters when something changes. You should be able to disable the agent without locking out the person who built it, remove one permission without breaking a shared integration, and read an audit record that names the agent rather than making every action look like it came from an administrator.

A shared staff login fails all three tests. So does one API key reused by several agents.

Access should match one job

Start with the job in ordinary language. Our illustrative enquiries agent reads messages sent to the support inbox, finds the matching lead, adds an internal note and drafts a reply. It does not need the finance system, the full SharePoint library or permission to change who owns a CRM record.

This is where broad role names become a problem. "CRM access" tells you almost nothing. Write down which records the agent can see, which fields it can change and whether it can act on every customer or only the one attached to the current task.

Time matters as well. Access needed for one import or repair job should expire when that work finishes. The ACSC guidance recommends short lived credentials and removing elevated access after a privileged task rather than leaving a permanent key in place because it may be useful later.

Put approval where damage starts

Approval on every step makes an agent slow and expensive. Approval nowhere turns a model error into a business action. The useful point sits immediately before an external consequence or a change that is difficult to reverse.

The line will differ by workflow, but it should be written down. Sending an email, moving money, deleting a source record, changing access and accepting a contract all deserve a person at the point of consequence. The ACSC guidance recommends mandatory human approval at decision steps and the ability to interrupt an agent while a task is running.

An approval screen also needs enough context for a person to make the decision. "Approve action" is useless. Show the message, the customer, the proposed change and the source material the agent relied on.

Logs belong in the build

An agent that works under somebody else's account produces a misleading record. The log may say an administrator changed a contact at 2:13am when the administrator was asleep and an agent retried the same task four times.

We want a record that answers practical questions.

• What started the task?
• Which customer records did the agent read?
• What action did it propose?
• Who approved it?
• What changed in the source system?
• Did the agent retry or call another tool?

You do not need to preserve every token the model produced. You do need enough information to reconstruct the business action and separate the agent from the people using it. The government guidance recommends monitoring prompts, tool calls, memory interactions, decisions, actions and changes to identity or permissions. That work is much easier when the agent has a name of its own.

Logs also need an owner. A record nobody reviews only helps after somebody has already noticed the damage.

Make every action reversible

Agents retry tasks. Networks fail halfway through an operation, APIs return ambiguous errors and a model may decide that running the same step again is the safest response. If the action creates an invoice or sends an email, a retry can become a duplicate with a customer on the other end.

Build the recovery behaviour alongside the successful path. The workflow should keep the original record, stop after an agreed retry limit and flag the right person when it cannot finish cleanly. Where an action can be made safe to repeat, design it that way. Where it cannot, require a fresh check before the agent tries again.

The off switch belongs here too. Disabling one agent should revoke its access without taking down every automation or locking out the staff member whose credential it borrowed. That is another reason its own identity matters.

The launch gate

The launch decision does not need a governance pack with a hundred pages. It needs clear answers about one agent and one job.

We use the same questions whether the agent is built with n8n, Copilot Studio or custom code. The implementation changes, but the access problem does not.

If you are planning an agent that will touch business systems, start by mapping one workflow and its control boundary. Our AI agent development work covers the build and the access design together. For an existing deployment with unclear permissions, an AI security review or AI data loss prevention assessment is the better starting point.

If nobody can name the account, the systems it reaches and the person who can stop it, the agent is not ready for production.