What is AI agent governance?
AI agent governance is the set of identities, permissions, limits, approval gates and records that control what a software agent may do once it can take actions on its own. AI agent governance answers four questions for every agent: who it is, what it may touch, which actions need a person first, and what record each action leaves behind.
Model governance covers what a system says. Agent governance covers what it does. An agent does not stop at drafting a reply. It sends the message, updates the client record, files the ticket, books the slot and closes the loop. The moment software writes into a business system, policy has to become something enforceable at the point of action rather than a paragraph in a handbook. Our wider view of AI governance sets that policy layer. Agent governance is where the policy turns into a permission, a queue and a log. We build these systems for South African businesses from Cape Town.
Why does AI agent governance matter once agents take actions?
An action cannot be unread the way an answer can. A clumsy sentence in a chat window is embarrassing. A message sent to the wrong client list, a record overwritten in the CRM, a supplier order raised twice or a calendar cleared by mistake is an operational event with a cost and a phone call attached.
The risk changes shape again once a business runs several agents at once. One answers enquiries, another chases documents, a third handles scheduling, a fourth cleans up records overnight. Each holds credentials. Each can act at three in the morning with nobody watching, and two of them can act on the same record within the same minute. Nobody can hold that in their head. The business needs a boundary it set on purpose, written where the agents run, rather than an assumption that each agent will behave the way it did in testing. That boundary is what AI agent governance provides.
What does a scoped agent permission actually control?
A scope controls four things: the systems an agent can reach, the operations it may perform in each, the records it may touch, and the volume it may push through in a window. An agent answering billing questions gets read access to invoices and nothing more. An agent that books appointments can create a slot and cannot delete a client.
Scopes hang off the agent's own identity and its own credentials, never a staff login. An agent should never inherit a manager's reach because somebody was in a hurry on setup day. Separate identities also make the log readable, since every action carries the name of the agent behind it. Alongside the scopes sit blunt limits: how many messages an agent may send in an hour, how many records it may change in one run, and which fields stay read only whatever the instruction says. Our agent governance and safety setup is where these scopes get written and tested.
Which agent actions should wait for a person?
An action waits for a person when it is outward facing, expensive, hard to reverse, or unusual for that agent. In practice that means a first message to a new contact, anything that commits money, deletions and bulk edits, changes to permissions or to the automations themselves, and any action that falls outside the pattern that agent normally follows.
The approval has to land where the team already works, in a queue or a chat channel, with the intended action, the reason behind it and the evidence attached. Approving should be a decision, not a guess. A request reading only "agent wants to send 240 emails" gets waved through, and the gate stops meaning anything. Everything routine keeps running unattended, because a system that asks about every step trains people to approve on autopilot. We build these gates as an AI human approval workflow system that sits between the agent and the send button.
What does the audit trail behind an agent action contain?
A useful trail records which agent acted, under which identity and scope, what triggered the run, the inputs it read, the action it took, the system that received it, the result returned, and whether a person approved it first. Prompt and workflow versions are stamped on the record, so a change in behaviour can be traced to the change in configuration that caused it.
Trails are written as the action happens, not reconstructed afterwards from whatever the systems kept. A log assembled after the incident is a story, not evidence. Blocked attempts are recorded too, because an agent reaching outside its scope is the earliest signal that a scope or an instruction needs work. Retention windows are set per record type rather than kept forever, personal information in the trail is minimised, and access to the log is itself controlled and logged. That keeps the trail POPIA-aware instead of a second copy of the client database.
How does a business start with AI agent governance?
Start with an inventory, not a policy document. List the agents already running, the credentials each one uses, and the actions each one can take today. That exercise almost always surfaces at least one scope wider than anyone intended, usually an agent running on a shared login nobody has revisited since the build.
From there the work is ordinary. Give every agent its own identity, cut its scope down to the job it actually does, name the handful of actions that need a person, and switch on the trail. Run it in a narrow lane first, on one workflow with real traffic, and widen once the log shows the agents behaving as described. The business owns everything we build: the workflows, the prompts, the scopes and the logs. We have worked this way with 35+ companies over 3+ years, and the same approach carries into the AI agents we build in South Africa.
Related capabilities. The same parts, your business.
Keep reading. Pages close to this one.
Tell us what your agents can reach. We will show you what to close.
Send one message describing the agents running in the business and what each one is allowed to do. We reply with an honest read on where the scopes are too wide, which actions belong behind a person, and what the trail should record.