I use coding agents every day. Having an agent write a fix and run the tests is useful. Having it run a shell with access to credentials is also a security decision, whether I’m thinking about it at the time or not.
When people ask me what AI governance means for a team using these tools, I start with two responsibilities:
You can explain what your agents did. You can stop actions they should not take.
There is more to governance than that, but those two sentences give us something concrete to examine.
The first sentence is about the record
Suppose a security lead asks what an agent did on a particular laptop yesterday. The answer should include the action it attempted, the policy that applied and what happened next. Did the command run? Did a rule block it? Did someone approve an exception?
A chat transcript can help explain the surrounding task. It may not contain the full tool arguments or the decision made by an external control. It may also have a different retention period from the records the company needs to keep. That is why I want the action record to exist separately from the conversation.
For example, an event that says “credential access blocked” leaves questions unanswered. Which credential path? Which agent? What rule? A useful record lets someone follow the decision back to those details without reconstructing the whole session from memory.
The record also needs care. Access restrictions matter because command arguments can contain sensitive information. Retention matters because a record that has already expired cannot help with an investigation. And someone needs to check that the agents expected to report are actually reporting.
The second sentence is about the gate
An agent encounters instructions in more places than the user’s prompt. A README, a retrieved document or a response from a Model Context Protocol tool can contain text that tries to redirect it. An ordinary mistake can cause harm too, especially when the agent has more access than the task needs.
OWASP’s guidance on Excessive Agency describes this in terms of excessive functionality, permissions and autonomy.[1] The practical response begins with limiting what the agent can reach and checking consequential actions before they run.
The distinction becomes obvious with a credential file. A policy might say that an agent must not read an SSH private key. The useful question is what happens when it tries. A control on the execution path can check the attempted read and refuse it. A written rule on its own cannot do that.
Existing permissions and sandboxes are part of the answer. Anthropic’s sandboxing work, for example, restricts filesystem and network access.[2] Endpoint and network controls still matter. An additional policy check has to fit into that deployment and cover a clearly defined path.
How the check and the record fit together
This is the division we use in AgentShield and AI Agent Lens.
AgentShield evaluates supported shell commands and MCP tool calls through configured hooks or proxies. It returns block, audit or allow, with the rule and reason. It analyzes the submitted action without executing it. The hook or proxy then applies the decision according to the configured mode.
AI Agent Lens collects audit events from connected installations so a team can review activity and manage shared policy. Local evaluation does not require a model call. Connecting an installation to the platform sends audit events and heartbeats, so the team needs to review what those records contain.
The audit trail uses hash chaining to make changes detectable when the chain is verified. That helps protect the integrity of the record. It does not tell us whether an action that bypassed the integration happened elsewhere. Coverage has to be checked separately.
What this looks like in daily work
A team can start with audit-only mode to see which actions its rules would block. The work continues while the team reviews those decisions. If a rule repeatedly flags legitimate work, that deserves attention before the team relies on it for enforcement.
Counting blocks is not enough. A hundred blocks might be a useful control doing its job, or one noisy rule interrupting the same task over and over. The people doing the work need a way to report the difference. Exceptions should have an owner and an explanation.
Once a team enables blocking, it should test that the control works on the intended integration. It should also test what happens when the integration is missing or unavailable. AgentShield can miss unfamiliar attacks and actions outside its configured paths. Our account of a bypass in an earlier version is one example of why those boundaries need testing.
Reports and control mappings can help explain this work during a security review. They do not establish that an entire organisation meets a standard. The evidence has to show which systems were covered, which policy applied and what the control actually did.
That is what I want from governance in day-to-day engineering. When an agent tries something it should not do, the team can point to the decision, explain it and check that the restriction worked.