Agentic AI Governance: Put Control Where Agents Act

Key takeaways

• A model policy describes intent. The execution boundary decides what an agent can actually do.
• Authority and capability are different things. A permitted action can still need a human decision.
• Frameworks organize risk. They do not make any runtime architecture safe on their own.
• Repeatable steps belong in deterministic apps with state and logs. Judgment stays with the model and with people.
• Run the pre-production checklist below before an agent touches a system of record.

What the CIO and CISO actually need to know

Most agentic AI governance programs govern the wrong object. They approve a model, publish a responsible-AI policy, and then let an agent loose on a ledger with a service account that can do far more than the policy imagines. The model was reviewed. The action was not.

Agentic AI governance, as I'm using the term here, is the set of controls that define what an agent may decide and do, who stays accountable for it, and how its actions are monitored and reviewed over time. The test is simple. If an agent takes an irreversible action today, can you show who authorized that class of action, which credentials it used, what it did, and who can stop it?

The distinction that matters most is between systems that recommend and systems that execute. A recommending system produces text a person reads. An executing system changes records, sends messages, and moves money. Governance effort should scale with the second kind, because that is where an error becomes an incident rather than a bad draft.

OWASP has put real weight behind this framing. Its State of Agentic AI Security and Governance 2.01, dated June 1, 2026, positions itself as a practical guide for building, managing, and deploying agentic applications, aimed at developers, security professionals, and decision-makers. The same page lists a separate Agent Control Standard dated September 1, 2026. NIST's AI Risk Management Framework, released January 26, 2023 and described as intended for voluntary use, organizes the work under four functions: Govern, Map, Measure, Manage. Both are useful. Neither tells you which of your agent's tool calls should require a signature.

This piece does not cover model evaluation, bias testing, or regulatory mapping by jurisdiction. Those are real problems with their own literature. It also overlaps with, but does not repeat, our broader writing on enterprise AI governance. The scope here is agents that act.

The argument: governance must travel with authority

Governance fails when it lives in a document and the authority lives in a system. The fix is to make them the same artifact, so the control exists at the point where the action happens. We have argued before for governance at the point of action. Four commitments follow from it.

Define the agent's authority before deployment

Write down, per agent, an accountable business owner, a technical owner, the resources and actions it may touch, the data boundary it operates inside, the human on whose behalf it acts, and the outcomes it must never produce. This is a short document. Its job is to exist before the first run, because retrofitting authority after an incident means arguing about intent with no record of it.

Separate authority from capability. An agent can technically be able to send an email to a customer. Whether it is allowed to is a decision someone made, or failed to make. Drafting the email and sending the email are different grants.

Enforce controls at runtime

A policy that the model is asked to follow is a request. Enforcement happens in code the model cannot talk its way past. That means a distinct identity for each agent, credentials scoped to the narrowest task, an authorization check on every action, approval gates on the high-impact ones, and a way to revoke access that takes effect immediately rather than at the next deployment.

Prompt injection makes this non-negotiable. If untrusted content can change what the model decides to do, the only reliable defense is that the decision cannot exceed what the credentials allow. Our piece on AI agent security covers the threat model in more depth.

Preserve evidence and accountability

Accountability stays with the organization and with named people. It does not transfer to the agent. What makes that real is evidence: a log of each action, the identity that took it, the approval that preceded it, the result, and a path for responding when something goes wrong. Observability for AI agents is the monitoring half of this. The audit trail is the retrospective half. You need both, and you need the ability to reconstruct what happened in March when an auditor asks in October.

Separate repeatable execution from model judgment

This is the commitment most governance guidance skips, and it is where we take a position. Every step an agent re-reasons on every run is a step whose behavior is probabilistic, whose cost scales with usage, and whose reasoning is hard to inspect after the fact. Most of an agent's workload is not judgment. It is the same lookup, the same reconciliation, the same record update, run again.

When an agent works out how to do a repeatable step, it should build an app for that step and run the app from then on. The app is deterministic code. It holds its own data in a managed database, keeps its files, and writes its own logs. Permissions attach to the app. An auditor reads code and logs instead of inferring behavior from a transcript. The agent still reasons about exceptions, ambiguity, and anything new. The model does less, not nothing.

What good looks like in practice

Consider an illustrative design, not a customer story. A finance agent handles overdue invoices. It reads the invoice and the contract, reconciles the payment record, drafts a collections note, and proposes a ledger update.

The reconciliation and the ledger lookup are repeatable, so they run as an app. The agent holds read access to the contract store and invoice data. It can draft the note without any approval. Sending the note to a customer, or writing to the ledger, requires a person to approve in the same app they use to manage the work. The approval record, the draft, the action, and the result land in the app's log. If credentials are revoked mid-run, the next write fails closed.

That one flow touches every stage of the lifecycle.

| Lifecycle stage | Control | Evidence artifact | |---|---|---| | Design | Authority document: owners, permitted actions, data boundary, prohibited outcomes | Signed authority record | | Identity and access | Per-agent identity, scoped credentials, role-based access on each app | Access policy and credential inventory | | Testing | Replay of representative and adversarial cases, including injected instructions | Test results tied to the app version | | Deployment | Review of the app and permissions before release; approval thresholds set | Release record | | Runtime monitoring | Action logs, anomaly alerts, drift checks on exception rates | Audit trail and monitoring dashboard | | Incident response and retirement | Revocation path, rollback, owner on call, decommission procedure | Incident record and retirement sign-off |

The first column is what many programs already have in some form. The third column is what they usually cannot produce on request.

Where governance frameworks stop short

Frameworks are scaffolding. They are not certifications, they are not legal advice, and none of them implements a control for you.

| Framework or source | What it helps govern | What the organization must operationalize | |---|---|---| | NIST AI RMF | Organizational risk practice across the AI lifecycle, structured as Govern, Map, Measure, Manage | Concrete owners, thresholds, and tests for each agent, plus the runtime enforcement that makes them real | | NIST Generative AI Profile (AI 600-1) | A cross-sectoral companion to the AI RMF for generative AI risks, published July 26, 2024 | Selection of the relevant risks and suggested actions for your agents, and mapping them to controls in your systems | | OWASP State of Agentic AI Security and Governance 2.01 | Security and governance of agentic applications, with frameworks, governance models, and regulatory standards surveyed | Translation of guidance into identity, authorization, logging, and approval gates in your own stack |

I read the NIST and OWASP landing pages directly. The detailed risk lists and suggested actions in AI 600-1 and the OWASP report sit in the full documents, and you should read those before citing specifics to a board.

The gap is architectural. A framework can tell you to map risks and manage them. It cannot tell you whether your agent's behavior on the repeatable parts of a workflow is the same on Tuesday as it was on Monday. That property comes from where the work executes. It does not come from a framework.

Deterministic apps have limits too. They make repeatable steps more consistent and easier to inspect. They do not remove the need to evaluate the model on the judgment calls that remain, and they do not protect against a compromised credential, a wrong policy, or an agent that drifts on the exceptions. Residual risk stays. The goal is to shrink the part you cannot inspect.

What are some effective governance frameworks for agentic AI?

Start with the NIST AI RMF and its Generative AI Profile for the organizational risk structure, and read OWASP's agentic security and governance resources for the threat and control detail specific to agents. Treat them as inputs to your operating model. Then answer the questions no framework answers for you, which fit on one page.

Before moving a workflow from pilot to production, check each of these:

1. Does the agent have a named business owner and a named technical owner?
2. Is its authority written down, including actions it must never take?
3. Does it run under its own identity with credentials scoped to the task?
4. Are high-impact actions behind an approval gate enforced in code rather than in the prompt?
5. Can you revoke its access immediately, and have you tested that?
6. Are repeatable steps running as deterministic code with their own logs?
7. Can you reconstruct, for any past action, the tools available, the decision, the approval, and the result?
8. Is there a defined incident path and an owner for it?
9. Has the workflow been tested against injected instructions and bad inputs?
10. Is there a review date and a retirement procedure?

If any answer is no, the workflow is a pilot.

What we're doing about this at Major

Our position is that governance should be structural. It belongs where work executes, in the same artifact people manage and agents run, and not in a document wrapped around a model.

Major is the enterprise platform where agents build the software they run on. When an agent figures out a repeatable part of a task, it builds an app for it. That app carries a managed database, storage, scoped permissions, and logs. People use the app as the control surface. The agent executes through it. IT governs both from the same place, with role-based access and audit trails that apply where the action lands.

This does not make an agent infallible, and we do not claim it removes the model. Judgment and exceptions still run through reasoning, and those need evaluation, monitoring, and human review. What changes is the share of the work that is inspectable. The more of an agent's repeatable work lives in code, the less of your audit depends on interpreting a transcript.

That is the operating principle behind the line we keep returning to: reason once, run forever. It describes how work gets built, not a promise of zero incidents.

To see how Major keeps agent actions inside scoped permissions and logs them where they happen, read how Major governs agent apps from the first deploy.

Related articles

• AI Agent Access Control: Scope Permissions Where Agents Act
• Agent Observability: What Deterministic Apps Change
• Enterprise AI Strategy: Build for Repeatable, Governed Work