Your AI Agent Has Employee-Level Access, So Who Is Watching What It Does?

Last Updated: 30 October 2026

Your agent has employee-level access because somebody gave it a service account to prove the pilot worked, and nobody took the access away when the pilot became production. That is the whole problem in one sentence. The model is not the risk. The credentials are.

The numbers are stark. Research surveying 800 IT leaders across the UK and US found that non-human identities outnumber employees in 83% of organisations, and only 21% have controls in place to govern them. The same research found that a quarter of organisations require human review before high-risk AI actions, down from 40% six months earlier. Access is spreading faster than the controls that should contain it.

This post covers what employee-level access actually means, why a shared service account is the wrong identity for an agent, what a real least-privilege design looks like for an accounts-payable agent, where approval gates belong, what an audit trail has to capture, and what all of it means for an Australian business. The short version: treat every agent like a new starter, and give it a lifecycle.

What does employee-level access actually mean for an agent?

Employee-level access means the agent can do what a person in that role can do: read records, send messages, change fields and trigger downstream systems. The difference is that the agent has none of the controls a person has. It has no manager, no role description, no exit interview and often no separate identity at all. It inherits whatever the account that launched it can reach, and it keeps that reach after the person who launched it changes role.

That gap is what Antoine Jebara described in IT Pro on 29 October 2026. "Every AI agent entering a customer environment becomes part of its digital workforce," he wrote. "It can hold credentials and make decisions, yet its identity may never appear in the processes used to govern employees."

The practical consequence is that joiner, mover and leaver processes do not apply. A person joins, gets a role, gets reviewed and gets deprovisioned. An agent gets created inside a SaaS platform, inherits its creator's permissions, and stays active indefinitely. IT Pro puts it plainly: temporary access has a habit of becoming permanent.

Autonomy makes the same old identity weakness worse. A human with excessive access moves slowly and leaves a trail of calendar invites and emails. An agent with excessive access moves at machine speed, in parallel, without a coffee break and without a paper trail unless you build one.

Why is a shared service account the wrong identity for an agent?

A shared service account is the wrong identity because it destroys attribution. If four agents and three scripts authenticate with the same key, the audit log records the key, not the actor. When something goes wrong you cannot say which process read the customer table, which one changed the supplier record, or which one posted to Slack. You have a timestamp and a credential, and that is not enough to answer a question from a board, a client or a regulator.

A distinct identity per agent fixes three things at once. It gives you attribution, because every action maps to one agent. It gives you a clean revocation path, because disabling one identity does not break the other six. And it gives you a permission set that can be scoped to the agent's job rather than copied from the person who deployed it.

The fourth thing it gives you is a lifecycle. An agent identity can carry an owner, a purpose, a creation date and an expiry date. When the expiry date arrives, someone has to justify the renewal. That single field is the difference between a governed fleet and an accumulating pile of keys nobody remembers issuing.

There is a cost. Distinct identities mean more secrets to manage, so you need somewhere to keep them that is not a spreadsheet or a .env file on a laptop. A secret manager is not optional once you pass two or three agents, and neither is a process for rotating credentials without breaking the workflow.

What happens when one agent can reach untrusted input and protected data?

It becomes a bridge. Security researchers recently demonstrated that GitHub Agentic Workflows could be manipulated into retrieving information from private repositories and publishing it in public comments. A routine issue became a route between untrusted input and protected information, because the agent could access both sides at once. No exploit chain was required. The architecture did the work.

This is the pattern worth internalising, because it generalises. An agent that reads email and also writes to a CRM is a bridge between anyone who can send an email and your customer records. An agent that reads a public webpage and also holds a database credential is a bridge between the open internet and your data. The agent does not need to be malicious or broken. It only needs to be reachable from both ends.

OWASP's guidance for agentic applications names this family of failure directly. In the LLM Top 10 for 2025, LLM06 Excessive Agency is defined as the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated outputs from a language model, regardless of what is causing the model to malfunction. The entry breaks it into excessive functionality, excessive permissions and excessive autonomy, and recommends minimising extensions, minimising permissions and requiring human approval.

Note what that definition does not say. It does not blame the model's judgement. It blames the amount of agency the system was given. You cannot patch your way out of a permission you should never have granted.

What does least privilege look like for a real agent?

Least privilege for an agent is defined by its job, not by the person who deployed it. Take an accounts-payable agent. Its job is to read invoices, extract the fields, check them against a purchase order and draft a payment run. That job needs read access to the invoice store, read access to purchase orders and write access to a draft payment batch. It does not need the ability to approve the run, change supplier bank details, or delete a record.

Those three excluded actions are not arbitrary. They are the irreversible ones. Approving a payment moves money. Changing bank details redirects money. Deleting a record destroys evidence. Each of them belongs behind a human approval gate, and each gate should be attached to the specific action rather than to the agent as a whole.

IT Pro makes the same point with the same example: an invoice-processing agent may need to read documents and update selected fields, while changing supplier bank details belongs behind an approval gate. The principle extends to anything that can make an irreversible decision or expose sensitive information.

The technical shape is a tool gateway. The agent never holds the credential for the ERP. It asks a gateway for a named tool, the gateway checks the request against an allowlist and the agent's scope, executes the call with a credential the agent never sees, and logs the result. The agent's reach becomes the tool list, not the network.

That design also makes the permission set auditable by a human. A list of twelve named tools with a sentence each is something a finance manager can read and challenge. A role with 340 entitlements is not. If nobody in the business can explain what the agent can do, nobody can approve it either.

Where do approval gates belong?

Approval gates belong on irreversible actions, on actions that move money, on actions that change identity and on actions that publish data outside the organisation. Everything else can run unattended. The useful test is to ask what the worst single call looks like, then put the gate in front of that call rather than in front of every call.

Blanket approval is a trap. If every action needs a click, people click without reading, and the gate becomes theatre. The same failure shows up in the data: the share of organisations requiring human review before high-risk AI actions fell from 40% to a quarter in six months, which suggests review is being removed where it was never meaningful in the first place.

Two design details make gates work. The first is that the approval request has to carry the context a human needs: what the agent wants to do, to which record, why, and what happens next. A gate that says "approve action?" is not a control. The second is that the gate must be enforced by the system, not by the prompt. If the model can skip the gate by calling a different tool, you have a suggestion, not a control.

A second person should approve anything that a single employee could not approve alone. That is a segregation-of-duties rule borrowed from finance, and it applies unchanged to agents. The agent drafts, a human approves, a second human releases.

What should an audit trail capture?

An audit trail needs five fields per action: which agent acted, what it touched, which policy allowed it, what the result was, and when the session ended. The record has to be queryable by a person who was not in the room, months later, without reading source code.

SailPoint's framing of the trust deficit is useful here. In a piece published through CIO on 30 October 2026, the company defines an AI trust deficit as the gap between what autonomous agents are doing and what a CIO can clearly explain to a board, auditor or regulator. Closing it requires audit-ready context: evidence showing who owns an agent, what it can access and which policies governed its decisions.

The same piece cites Omdia research that more than half of enterprises are already deploying agentic AI, and notes that some enterprises now manage roughly 45 machine identities for every employee, with 67% of leaders concerned about the security risk those identities pose. Those figures come from a vendor-sponsored piece, so treat them as directional rather than definitive. The direction is still uncomfortable.

Session-level logging is the piece most teams miss. If each agent session runs in its own isolated environment, you can tie every action to a session, and every session to a start time, an end time and a deletion event. That is a much stronger claim than a log line that says a tool was called at 14:32.

What does this mean for an Australian business?

For an Australian business the practical issues are the Security of Critical Infrastructure Act reporting obligations if you operate a critical infrastructure asset, ASD's Essential Eight maturity model, and the OAIC's expectation that organisations can explain how automated decisions affecting individuals are made. None of those frameworks name AI agents explicitly. All of them assume you can say who did what, with which authority, and when.

The Essential Eight is the most useful of the three for this problem, because it already contains the controls that matter: restrict administrative privileges, patch applications, multi-factor authentication, and application control. An agent with employee-level access is an administrative privilege problem wearing a new hat. If your Essential Eight maturity is low, adding agents does not raise it. It gives you more places to fail.

There is also a data custody question. If the agent runs on a vendor's infrastructure, the tool calls, the prompts and the results sit with the vendor, and your audit trail is a copy of somebody else's log. If the agent runs on hardware you control, the trail is yours. That difference matters when a client asks where their information went.

None of this is legal advice. The point is narrower: the frameworks you already report against assume attributable action. An agent without a distinct identity breaks that assumption, and no amount of model quality repairs it.

How do you start without boiling the ocean?

Start with an inventory, not a policy. List every agent in the environment, the credentials each one uses, the systems it can reach and the person who owns it. Most businesses find agents they did not know about, created inside a SaaS platform or by a team experimenting outside IT. The inventory is the first control, because you cannot govern what you cannot name.

Then work through the list in order of reach. The agent with the widest access gets fixed first: a distinct identity, a job-scoped permission set, a gate on its worst call, a log and an expiry date. Do not start with the easiest agent. Start with the one that could move money or publish data.

Write the scope in language the business can read. "Can read invoices, can draft a payment batch, cannot approve or change bank details" is a scope a finance manager can sign. "Has accounts-payable role" is not. The readable version is also the version that survives staff turnover, because the next person inherits a sentence instead of a mystery.

Finally, test the off switch. Disable one agent in a staging environment and confirm that its credentials stop working, its sessions stop running and its logs stop writing. An agent you cannot turn off is not under control, whatever the policy says. If you are mapping this for a real workflow, our piece on designing an agent around a real content pipeline covers the same scoping decisions from the build side. If you want a second opinion on an existing agent estate, talk to us.

Frequently asked questions

What is employee-level access for an AI agent?

It means the agent can do what a person in that role can do: read records, send messages, change fields and trigger other systems. The risk is that the agent usually has none of the controls a person has, such as a manager, a role review, a distinct identity or an exit process.

Should an AI agent have its own identity?

Yes. A distinct identity per agent gives you attribution in the audit log, a clean revocation path and a permission set scoped to the agent's job rather than copied from its creator. Shared service accounts make it impossible to say which process did what.

What is excessive agency in the OWASP Top 10 for LLMs?

LLM06:2025 Excessive Agency is the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model output. It covers excessive functionality, excessive permissions and excessive autonomy, and the recommended controls are to minimise extensions, minimise permissions and require human approval.

Which actions should require human approval?

Irreversible actions, anything that moves money, anything that changes identity or access, and anything that publishes data outside the organisation. Gate the worst call rather than every call, because blanket approval trains people to click yes without reading.

How many organisations have more machine identities than employees?

Research surveying 800 IT leaders across the UK and US found non-human identities outnumber employees in 83% of organisations, with only 21% having controls in place to govern them. The research was reported by IT Pro on 29 October 2026.