Agent Governance: Who Is Responsible When AI Can Take Action?

Chatbots Versus Agents

The useful distinction is not conversational sophistication. It is capability. Does the system only produce text, or can it invoke tools that read and write real systems? Once the answer is 'write', governance is no longer optional and cannot be retrofitted from a policy document.

Agent Identity

An agent must be a first-class identity in the enterprise directory, not a shared service account with a generous role and a key in a config file. It needs an owner, a scope, a lifecycle and a place in the audit log.

Then a second question follows immediately: does the agent act as itself, or on behalf of a user? Both models are legitimate and they produce very different systems. A delegated-permission agent can only reach what the requesting user could reach — which is naturally safe and naturally limited. An agent with its own permissions can serve many users consistently, but its permissions become the ceiling for everyone, and per-user filtering becomes the application's responsibility.

Read Versus Write, and Least Privilege in Practice

Separate the two explicitly. Most useful agent behaviour is read-heavy: gathering status, checking a record, assembling context. Write capability should be enumerated tool by tool, each one justified, each one scoped to the narrowest possible target.

• Grant tools, not systems: 'create a work order for property X' rather than 'access the property management API'.
• Bound every write by scope — record type, tenant, region, monetary limit.
• Make destructive and financial actions a different class with different controls.
• Expire and review permissions like any other privileged access.

Approval Gates and Human in the Loop

Human review is a design tool, not an admission of weakness. Place gates where reversal is expensive and confidence is uncertain, and leave them out where the action is trivially reversible and the volume is high — otherwise reviewers rubber-stamp and the gate becomes theatre.

A practical example: an operations agent may chase a vendor for a schedule indefinitely, may draft an invoice approval, but may not release payment. The threshold is a business decision documented once and enforced by the platform.

Logging, Observability and Auditability

For any action an agent took, someone will eventually ask four questions: what did it do, why did it do it, who authorized the capability, and what was the state before. If the system cannot answer all four, it is not auditable.

• Record the trigger, the retrieved context, the tool calls with parameters, the outcome and the identity used.
• Correlate agent activity with the downstream system's own audit trail.
• Keep decision logs queryable by business object, not just by timestamp.
• Agree retention and redaction with privacy and compliance before launch.

Cost Controls

Agents decide how much work to do. A retry loop, an over-eager planner or a badly bounded tool can generate a surprising bill overnight. Per-agent budgets, step limits, timeouts, quota alerts and a hard stop are ordinary engineering hygiene here.

Agent Lifecycle, Exceptions and Kill Switches

Agents are software with permissions, so they need the full lifecycle: proposal and risk review, staged rollout, monitoring, periodic re-certification of permissions, and decommissioning with credential revocation. Exception handling deserves explicit design — an agent that cannot proceed should escalate with context, not fail silently or loop.

Finally, every acting agent needs a switch that stops it immediately, operable by someone who is not the developer, tested before production. If disabling the agent requires a code deployment, there is no kill switch.

Tradeoffs Worth Naming

Practical Recommendations

• Classify every agent action as auto-execute, approve-then-execute, or recommend-only before building it.
• Give each agent its own identity with an accountable human owner.
• Enumerate tools individually; never grant broad system access.
• Log decisions in business terms so operations staff, not only engineers, can audit them.
• Set budgets and step limits, and test the kill switch.