Agents now hold credentials, call tools and take actions without a person in the loop. Almost no organisation has decided who answers for what they do. A practical way to govern them before the first incident makes the decision for you.
The shift happened faster than the governance did.
For two years the question about AI at work was whether staff were pasting sensitive material into a chat window. That was a real problem and we wrote about it in shadow AI at work. It is also, in hindsight, a comparatively gentle one, because the worst case was disclosure.
What is running in organisations now is different in kind. Agents hold credentials. They call internal tools. They read a ticket, decide what it needs, and do it. They open pull requests, move money between ledgers, grant access, send messages to customers, and they do it without a person approving each step, because approving each step was the entire cost saving.
Which raises a question that most organisations have not answered. When one of them does something harmful, who is accountable.
It is tempting to assume the model provider carries this. They do not, and their terms are explicit about it.
It is equally tempting to assume the answer is the engineer who deployed the agent, which is unfair in the same way that blaming the junior administrator for a policy failure is unfair. They implemented something the organisation asked for.
The workable answer is the same one that has always applied to delegated authority. An agent acts on behalf of somebody. That somebody is accountable for what it does inside the authority they gave it, and the organisation is accountable for the authority it allowed to be given.
Which means the governance question is not really about artificial intelligence. It is about delegation, and organisations have governed delegation for a very long time. What is missing is the decision to treat an agent as a thing that receives delegated authority rather than as a piece of software that was installed.
An agent is not a tool your staff use. It is a party your organisation has given authority to. Govern it as one.
The most common failure we see is an agent running with a shared service account, often one that predates the agent and carries permissions accumulated over years.
That single decision destroys accountability, because the log now shows that an account did something and cannot show which agent, which version, or on whose behalf. When somebody asks what happened, the honest answer is that nobody can reconstruct it.
Each agent needs its own identity, scoped to the narrowest set of permissions that lets it do its job, with credentials that rotate and an owner recorded as a person rather than a team inbox. This is not a new control. It is the service account hygiene that has been in every framework for twenty years, applied to a population that grew quickly while nobody was counting.
It is worth noting how this interacts with authentication generally. Agents are precisely the non human accounts that tend to sit outside multi factor enforcement, which is the gap we described in MFA is not the finish line. An agent with a static credential and broad permissions is an attractive target, and it will not notice anything unusual about being used at four in the morning.
Most organisations grant authority implicitly, by connecting an agent to a system and seeing what happens. That is how you discover your boundaries the expensive way.
A better approach is to decide deliberately, in three bands.
Things an agent may do alone, which should be actions that are reversible, bounded, and cheap to get wrong. Reading, summarising, drafting, classifying, opening a ticket.
Things an agent may prepare but not complete, where it does the work and a named person confirms. Anything that moves money, changes access, alters production configuration, or goes to a customer under your name.
Things an agent may not touch at all. Accepting a control as satisfied, approving its own access request, signing anything a regulator will read.
That third band matters more than it looks. We have written at length about where we draw this line in our position on AI in compliance work, and the principle generalises. The reading is a good job for a machine. The deciding carries accountability, and accountability needs a person whose name sits on it afterwards.
Ordinary application logs record that something happened. For an agent that is not enough, because the useful question after an incident is why.
What you want retained is the instruction it received, the context it retrieved, the tools it called with what arguments, what it returned, and which version of which model produced the decision. Without the model version you cannot reproduce anything, and a provider updating a model underneath you will otherwise look like an unexplained change in behaviour.
This is more data than teams expect and it is the difference between an investigation and a shrug.
Agents fail in ways conventional software does not, and the OWASP Top 10 for LLM Applications is the best current catalogue of them.
The one that surprises people most is indirect prompt injection. An agent that reads external content, a web page, an email, a document, a ticket raised by a customer, can be instructed by that content. The attacker does not need access to your systems. They need their text to reach an agent that holds credentials.
Then there is confused deputy behaviour, where an agent with broad permissions performs an action for a user who could not have performed it themselves. And there is chaining, where several agents call each other and authority compounds quietly across the hops.
The mitigation for all three is the same and it is unfashionable. Narrow the permissions. Treat everything the agent reads as untrusted. Keep the irreversible actions behind a person.
Our GRC practice helps organisations write the agent authority model and fit it to the frameworks they already answer to, which increasingly ask about automated decision making directly. Our VAPT team tests agent deployments the way an attacker would, including injection through the content an agent consumes rather than only through its interface.
On the platform side, the principle we build to is the one above. In CyberNexus and ControlGraph, machine work proposes and a named person accepts, and the acceptance is what the record keeps. We could have built the version that closes controls automatically. It demos better and it moves liability from a professional onto software, which matters enormously the first time it matters at all.
Count your agents. Most organisations cannot, and the number is higher than the security team believes, because agents arrive through product features rather than procurement.
For each one, write down three things. What identity it uses, what it is allowed to do without a person, and who owns it. Any agent where you cannot answer all three is the one to look at first.
Software that uses a language model to decide what to do and then does it, by calling tools and taking actions, rather than only producing text for a person to read and act on. The distinction that matters for security is that it holds credentials and changes real state.
In practice the organisation that deployed it. Model providers disclaim it in their terms, and the deploying engineer is rarely the right answer. The workable model is delegated authority, where an agent acts on behalf of an accountable person inside limits the organisation approved.
An attack where instructions are hidden in content an agent reads, such as a web page, email, document or support ticket, and the agent follows them. The attacker never needs access to your systems, only a route for their text to reach an agent that holds credentials.
Yes. Shared service accounts destroy attribution, because logs show that an account acted without showing which agent, which version, or on whose behalf. Each agent needs a scoped identity, rotating credentials and a named human owner.
The instruction received, the context retrieved, the tools called and with what arguments, what was returned, and the model and version that produced the decision. Without the model version, behaviour changes caused by a provider update are indistinguishable from a fault in your own system.
PISF turns security in Pakistan from something organisations were encouraged to do into something they are expected to evidence. What the framework covers, who it applies to, and where to start if you are beginning from very little.
Read the article
Pakistani organisations have been told to stand up security operations centres on a short timeline. Most of what gets built under that pressure watches everything and catches nothing. What a working SOC needs first.
Read the article
Moving data inside the country satisfies the letter of a residency rule and often changes very little about who can actually reach it. What the harder questions are, and what to ask a cloud provider before signing.
Read the articleIf this raises a question about your own compliance position or your security operations, the quickest route is a direct conversation.
