Running AI Agents in Production With Approvals, Audits, and RBAC

The pitch is seductive. Spin up a small team of agents to run finance, marketing, and ops the way a Chief Operating Officer would. One agent reconciles invoices, another drafts campaign briefs, a third updates ticket statuses in the CRM. The humans supervise. The business compounds.

The reality is that most of these deployments ship without a control plane. Only 19.7% of organizations say all their AI agents are fully secured and governed before going live in production, and Deloitte's 2026 research found that only 1 in 5 companies (21%) has a mature governance model for autonomous AI agents. The agents work. The operational scaffolding around them does not.

This piece covers that scaffolding. Three parts: the approval queue schema, the immutable audit log design, and the role-based permissions model. The point is not theoretical governance. The point is that a technical buyer can ship finance, marketing, and ops agents next quarter without taking on uncontrolled risk.

What an AI COO Team Actually Looks Like in Production

Treat each function as its own agent with its own tools. A finance agent that reads from the general ledger and proposes journal entries. A marketing agent that drafts campaigns and schedules sends. An ops agent that triages tickets, nudges vendors, and updates project status. They share memory through a vector store and coordinate through a message bus, but they do not share credentials.

The temptation is to give every agent broad write access and trust the prompt. That is how organizations end up as the 80% without governance. The alternative is boring: narrow tool contracts, scoped credentials, and a control plane that sits between the agent and anything it can break. We cover the authentication and tool-boundary layer separately in secure AI agents for ERP and CRM; the control plane assumes that layer exists.

The control plane has three jobs. Decide what needs human approval. Record what happened in a way nobody can quietly edit later. Make sure the agent only had the keys to the rooms it was supposed to enter. The rest of this piece is those three jobs.

The Approval Queue Schema

An approval queue is a database table, a worker that respects it, and a UI that a human reviewer actually opens. The schema matters because it is also the audit record: every row is both a pending decision and a permanent entry.

At minimum, each row carries a request ID, a correlation ID that links back to the agent run, the agent identity, the proposed tool call with full arguments, the agent's stated reason, the risk tier, the reviewer options, an expiration timestamp, and a decision field that starts null. Expirations matter. A stale approval reviewed three days late may authorize an action that no longer makes sense; the safe default is to let expired requests fail closed rather than execute.

Tier the actions. A rough split that works in practice:

• Tier 0 (auto-execute): read-only queries, internal drafts, status lookups.
• Tier 1 (single approver): outbound customer email, CRM updates, draft social posts, journal entry proposals under a dollar threshold.
• Tier 2 (dual control): payments, refunds, credential grants, production config changes, anything over the threshold.
• Tier 3 (blocked): actions the agent is simply not allowed to propose, regardless of reviewer.

Dual control is the quiet workhorse. Two independent approvers, neither able to act alone. This mirrors the posture Article 14 of the EU AI Act takes for high-risk systems, including a 'four-eyes' rule requiring that decisions from remote biometric identification be separately verified by at least two competent natural persons. The regulators landed on dual control for the same reason banks did: a second pair of eyes is cheap, and the failures it prevents are not.

Then there is the problem reviewers themselves create. Anthropic found that Claude Code users approve 93% of permission prompts, a pattern Anthropic calls 'approval fatigue,' and in one Anthropic study human reviewers caught only 13.6% of harmful actions while an automated classifier caught 89%. The lesson is not to remove humans. The lesson is to ask them rarely, show them full context, and let an automated policy layer handle the volume so the questions that reach a person are the ones worth reading.

Designing the Immutable Audit Log

The audit log is not the application log. It is a separate, append-only store whose job is to prove what happened in a way an auditor or an incident responder can trust. The agent process writes to it. The agent process cannot edit it.

Three implementation patterns show up in real deployments. A Kafka topic backed by write-once object storage with S3 Object Lock in compliance mode. A Postgres append-only table with hash-chained rows, where each row includes the SHA-256 of the previous row. A managed WORM store from the cloud provider. All three give you the property that matters: any modification to a prior record breaks the chain and becomes detectable.

Each entry should carry the timestamp, the agent identity, the session and correlation IDs, the event type (tool call, approval requested, approval granted, approval denied, policy violation), the exact arguments, the result status, a content hash of any input or output, and the identity that authorized the step. Log identity and policy decisions, not raw sensitive values. A content hash of a credit card number is auditable; the number itself in a log is a breach waiting to happen. OWASP's Logging Cheat Sheet covers the field hygiene in detail.

Retention is driven by the regulated workload the agents touch. PCI DSS Requirement 10 requires audit logs to be retained for a minimum of 12 months, with the most recent 3 months immediately available for review, and Requirement 10.5 mandates that audit trails cannot be altered. HIPAA pushes toward six years. SOC 2 is scoped by the auditor. Pick the longest window that applies, write it into the retention policy, and keep the storage class honest about it.

One subtle requirement: the log must be useful for replay. If the agent proposes a refund on Tuesday and the reviewer approves it on Thursday, you need to be able to reconstruct the state the agent saw on Tuesday to decide whether the approval still holds. That means logging the retrieval context, not just the tool call. Deterministic replay is also how you debug agent misbehavior without rerunning expensive inference against a changed world. The same discipline applies when you ship AI-written code into these systems, which we cover in auditing AI-generated code.

Role-Based Permissions for AI Agents

RBAC for agents is RBAC for humans with one twist. The agent is a principal. The reviewer is a principal. The tool is a resource. The policy decides which principal can invoke which tool against which resource in which environment. NIST defines role-based access control as access decisions based on the roles that individual users have as part of an organization; the model extends cleanly to non-human identities once you stop treating the agent as a user and start treating it as a service account with a narrower contract.

A workable model has four role layers:

• Agent roles scoped per function: finance-agent, marketing-agent, ops-agent. Each has its own credentials, its own tool allowlist, and its own data partition.
• Reviewer roles scoped per domain: finance-reviewer approves finance tier-1 actions, finance-approver pairs with the reviewer for tier-2.
• Operator roles for the humans who can pause, resume, or stop agent sessions and rotate credentials.
• Auditor roles that are read-only against the audit log and the approval queue.

Keep the agent on short-lived credentials with explicit scope. A finance agent gets a token that is valid for the current task, limited to the ledger read API and the journal entry proposal endpoint, and expires in minutes. It never holds a long-lived key to the payments API; that key lives behind the approval queue and is used by the executor only after human approval. The zero-trust posture that applies to internal services applies here with more force, because the agent is probabilistic and the blast radius of a bad tool call is immediate.

Separation of duties is the other half. The agent that proposes an action cannot be the identity that approves it. The reviewer that approves cannot be the executor that runs it. These are three distinct principals even when a single person is wearing two of the hats, and the audit log should record all three.

The framework landscape is still catching up. The NIST AI Risk Management Framework was published as NIST AI 100-1 in January 2023, organized around four core functions — Govern, Map, Measure, and Manage — and was developed before agentic architectures emerged as a mainstream deployment pattern. It is still the most-adopted reference, but teams are extending it with agent-specific controls rather than waiting for a tailored successor.

What This Looks Like When You Buy It

A buyer evaluating a vendor for an AI COO rollout should ask for four artifacts before signing. The approval queue schema and the tier definitions. The audit log retention policy and the tamper-evidence mechanism. The RBAC matrix mapping agents, reviewers, operators, and auditors to specific tools and data scopes. The incident playbook for revoking an agent's credentials mid-run. A vendor that cannot produce these on request is selling you a demo, not a system.

Budget realistically. The control plane is typically 20 to 35 percent of the build cost of the agents themselves, and the ongoing reviewer time is a line item, not an afterthought. The cost of a custom AI agent changes significantly once governance is in scope, and the honest number is the one with the queue, the log, and the RBAC included.

Agents are a tool, not a solution. The teams that get real work out of them are the ones whose owners can prove, with logs that stand up to an auditor, exactly which decisions the machines made and which ones a person signed off on. That proof is what the control plane is for.