AI Agent Governance: Permissions, Identity and Human Approval

A chatbot can say the wrong thing. An agent can do the wrong thing.

That single distinction is what AI agent governance is about. When a system gains the ability to read your CRM, draft quotes, issue refunds or trigger workflows, the interesting security question is no longer whether its output sounds right — it is what the system is allowed to do, on whose authority, with what proof. The World Economic Forum’s 2026 agent playbook puts authorization, oversight and auditability at the center of trusted agent adoption, and enterprise practice is following.

This is not a future concept. If you have an agent touching business systems today, governance is either something you built or something you are missing.

Why AI agent governance is different

Classic IT security governs people using tools. Model safety governs what a model says. Agent governance governs what a system is permitted to do on its own — a category neither of the others covers.

An agent combines four things that previously stayed separate: understanding (reads intent), knowledge access (retrieves your data), action (calls tools that change systems) and increasingly persistence (memory across sessions). Govern any one of them in isolation and the other three leak. Governance has to cover the loop, not the parts.

Capability is not authority

The core principle, aligned with how the WEF frames authorization:

Can the agent issue a refund?
        ≠
Is the agent allowed to issue THIS refund,
for THIS customer, at THIS moment?

A connected ERP makes the agent capable of issuing refunds. Capability arrives by default the moment you wire the integration. Authority is what you design: which actions, which scopes, which limits, which approvals. Every agent incident report you will ever read is a case where capability outran authority.

The seven controls every enterprise agent needs

We deploy agents against a fixed control checklist. We call it the KifferLiu Agent Control Model — a working model from real deployments, not an industry standard. Use it as a review gate before any agent touches production.

1. Identity          the agent is a named, separate actor
2. Authentication    its own credentials, short-lived
3. Authorization     least privilege, per tool and per data set
4. Data boundaries   what it may read, and what it must never see
5. Tool boundaries   which actions, with what limits
6. Human approval    irreversible or high-stakes steps gated
7. Audit + shutdown  every step logged; one switch kills it

1–2. Identity and authentication

Give each agent a service identity: its own credentials, its own scopes, its own place in your identity system. Never let the agent borrow a human’s account or a shared admin key. Identity is what makes every later control enforceable — you cannot scope, audit or revoke an actor you cannot name.

3. Authorization

Least privilege, concretely: the agent gets exactly the tool scopes its workflow needs and nothing more. A support agent that drafts replies needs write access to drafts — not to the billing system. Review scopes at design time, and again whenever the workflow changes.

4. Data boundaries

Decide what the agent may read, and — just as important — what it must never retrieve, even if a user asks: salary data, cost breakdowns, personal data beyond need. Boundaries live in the retrieval layer and permission checks around it, not in polite instructions inside a prompt. This is the layer where context engineering becomes governance: what the system can know is a design decision, made once, deliberately.

5. Tool boundaries

Tools are where words become actions. For each: is it read-only or mutating? Reversible or irreversible? Bounded by amount, count or scope? A send_email tool with no rate limit and no recipient allowlist is an open door with a job title.

6. Human approval

Not everything should require a human — that is just chat with extra steps. Gate exactly the actions that are irreversible, financial, externally visible or out-of-policy: refunds, cancellations, price overrides, contract language, bulk exports. Approval requests should carry the evidence — sources, numbers, the draft action — so the human reviews the substance in one screen.

7. Audit and shutdown

Every input, retrieval, tool call, permission decision and output, timestamped and attributable. BCG’s 2026 guidance for CIOs stresses the same components: identity, a registry of agents, runtime policy enforcement and circuit breakers. And there must be a kill switch — one action that stops the agent, mid-loop, without waiting for a vendor. If you cannot demonstrate that switch in a drill, you do not have it.

Example: a governed customer support agent

The fastest way to see all seven controls is one concrete agent. Scope for a customer support agent at an equipment manufacturer:

	Scope
Read	Knowledge base, customer profile, order history
Write	Draft replies, ticket tags, internal notes
Requires approval	Refunds, order cancellation, price override
Never	Export the customer database, read cost margins, send unreviewed bulk email

The “Never” row is the one most implementations skip, and the one auditors ask about first. It is also cheap: a deny rule costs less than any capability, and it is the row that makes the other rows believable.

Rolling out governance: from zero to first agent

Teams that already have agents and no governance do not need a program — they need an order of operations:

Phase 0   Register        list every agent that exists, what it
                          touches, who owns it (you will find more)
Phase 1   Read-only       identity, boundaries, audit for agents
                          that only read
Phase 2   Gated writes    mutating actions behind approval and limits
Phase 3   Bounded autonomy  pre-approved action classes run alone;
                          everything else still gates

Phase 0 is usually the eye-opener: in most mid-size companies the registry finds shadow automations nobody documented. The phases are deliberately boring — each one is a demo you can show leadership, and none requires halting existing work.

One ownership rule makes the whole thing stick: a named person owns agent governance, not a committee. Security, IT and the business all contribute, but the WEF playbook’s emphasis on authorization and accountability lands on a name, a budget and a review cadence.

Governance is a product feature

There is a commercial point hiding in this control list. In most companies, the deployment blocker for agents is not model quality — leadership simply cannot answer “what stops it from doing something stupid?” A team that can answer with identities, allowlists, approval gates and audit logs unblocks the deployment. Governance done well reads as competence, to customers and to regulators alike.

The prerequisite underneath all of it remains knowledge quality: an agent acting on governed, current, permissioned knowledge inherits that trust; an agent acting on a mess inherits the mess. Start with knowledge governance — or score your foundation first with the AI knowledge readiness checklist.

Agents that act need more than guardrails.

Identity, permissions, approval loops, audit and a kill switch — designed in, not bolted on. That is how we deploy agents that touch real business systems. See how we build business AI systems.