How do you govern AI agents?

Govern agents at three points: authenticate the agent and scope its permissions to the task, keep a durable log of every action it takes, and set containment boundaries on what it can do autonomously. Each has to be enforced where the action happens, at the query layer, rather than described in a policy document. Major applies all three at the app layer, where agents act through deterministic apps with scoped credentials and role-based access checked before the write commits.

What is the NIST AI RMF?

The NIST AI Risk Management Framework (AI RMF 1.0, NIST.AI.100-1) is the US baseline framework for managing AI risk, released in January 2023 and being revised. It organizes the work into four functions: Govern, Map, Measure, and Manage. It defines what trustworthy AI requires without prescribing an implementation, so enforcement is left to the adopting organization.

Does the EU AI Act require audit logs?

Yes. Article 12 (Record-keeping) requires that high-risk AI systems technically allow for the automatic recording of events, logs, over the lifetime of the system. The logs must support identifying risks and monitoring how the system operates. That record is easiest to produce when the agent's work runs as a deterministic app, which is how Major logs each agent action and exports it to a SIEM.

What is the difference between AI governance policy and enforcement?

Policy states intent: who should be allowed to do what, what should be logged, where autonomy should stop. Enforcement applies that intent at the point of action so it cannot be bypassed. A permission described in a document but never checked at the query is a preference. A permission checked by the system before the action commits is a control.

How do you audit what an AI agent did?

Audit the actions rather than the prompts: for each step, record which identity authorized it, which system it touched, what it changed, and the result, in a store the agent cannot quietly edit. A trace of prompts and completions debugs the model but will not tell an auditor what changed in Salesforce at 14:32. On Major, that entry is written where the agent acts and is exportable to your SIEM.

Enterprise AI Governance: From Policy to Implementation

Enterprise AI governance means governing the actions AI agents take, enforced where the action happens rather than in a policy document that nothing checks.

Rahul RamakrishnanJuly 20, 2026Updated October 21, 2026

Office worker reviewing printed documents beside a laptop at a desk

Enterprise AI governance is the set of controls that keep AI systems accountable in production. For autonomous agents, that means governing the actions an agent takes, not just the text it produces. The controls that hold up are enforced where the action happens: a known identity, a durable action log, and hard boundaries on what the agent can do. A policy document that nothing checks at the point of action is theater.

Major is built around that position. It is the enterprise platform where agents build the software they run on, so an agent's repeatable work runs as a deterministic app with scoped credentials, role-based access, and audit logging applied where the agent acts. The rest of this piece explains why that placement matters and gives you a checklist to take into your next vendor review.

What does a CIO or CISO actually have to decide?

Ask most governance programs one question and the room goes quiet. At the moment an agent took an action last Tuesday, whose permissions did it use, and where is the record? If the honest answer is "a service account and a model trace," you have a policy, not a control.

The gap is the distance between a governance document and the place where an agent acts. A maturity model on a slide does not stop an over-permissioned agent from deleting the wrong records.

Agents make this harder than earlier AI did. One run can touch five systems, make a dozen decisions, and leave side effects in each. If the evidence lives in the model's context window, it disappears when the run ends. Three months later, when a customer disputes a change or an auditor asks who approved it, you are reconstructing intent from logs that were never designed as an audit trail.

What do NIST, the EU AI Act, and OWASP agree on?

The NIST AI Risk Management Framework (AI RMF 1.0, NIST.AI.100-1, released January 2023 and being revised) organizes AI risk work into four functions: Govern, Map, Measure, and Manage. It says what to achieve and stays neutral on how.

The EU AI Act is more prescriptive where it counts. Article 12 requires that high-risk AI systems technically allow for the automatic recording of events, logs, over the lifetime of the system. The OWASP Top 10 for LLM Applications (2025) ranks Excessive Agency as LLM06:2025: an agent able to take actions beyond what the task required because its permissions, tools, or autonomy were too broad.

Read across all three and the list is short. Know who is acting. Record what they did in a way you cannot quietly edit. Bound what they are allowed to do. Almost none of these documents shows you how to enforce that inside an agent stack.

In February 2026, NIST's Center for AI Standards and Innovation launched an AI Agent Standards Initiative, including a Request for Information on securing AI agent systems and an NCCoE concept paper on agent identity and authorization. The work is still at the comment stage, so treat the themes below as themes, not a fixed standard.

Which three controls matter most for agents?

Identity and authorization. An agent acting through a shared service account is unattributable by construction. You can see that the account did something, not which person or task was behind it, and the account almost always holds more access than any single run needs.

Action logging. A trace of prompts and completions debugs the model. It does not tell a regulator what the agent changed in the system of record at 14:32. You need a durable record of actions, not only model calls.

Containment. Containment decides what the agent is structurally unable to do, whatever it decides in the moment. It maps directly to OWASP's Excessive Agency. The goal is to make the unsafe action impossible to issue, so a bad plan hits a wall instead of production data.

What does enforcement at the point of action look like?

Take an agent updating a Salesforce opportunity. Under run-as-invoker identity, the agent does not hold its own broad credential. It acts as the person who started the run, carrying that user's scoped OAuth token. If the user cannot edit the record, the agent cannot either, because Salesforce's own RBAC refuses the write. The agent does not choose to respect the check. It happens upstream, at the query.

The audit record falls out of that design: this user, at this timestamp, invoked this app, which issued this write to this Salesforce object, with this result. You can hand that to a regulator or replay it during an incident.

Use this as the vendor test. For every row, ask whether the control is enforced where the action happens or only written down.

Identity: run-as-invoker, so upstream RBAC is mirrored rather than bypassed
Logging: every agent action logged like any other application query, exportable to your SIEM
Containment: the agent acts only through deterministic apps with typed inputs and RBAC enforced at the query layer
Human oversight: approval gates on restricted actions, routed to a person in Slack before the action commits
Change control: version-pinned apps with rollback to a known-good version

Where do vendors get agent governance wrong?

Three patterns recur, and each swaps a gesture for a control.

The first is governance as a UI dropdown. A permissions screen and a policy toggle exist, but enforcement lives in the prompt or in application code the agent can route around. A setting the runtime does not enforce is a preference.

The second is the broad service-account credential. Every action is attributed to one robot account, so you lose the who, and the agent can reach far past any individual task, so you lose containment.

The third is treating LLM observability as agent governance. Prompt and token traces are useful. They record what the model produced, not what the agent then did to your systems. A CISO who accepts a model trace as the audit trail has accepted a record of intentions in place of a record of actions.

How to build governed agents on Major

This is how the controls above map to a concrete build on Major.

Connectors: connect Salesforce, Slack, and your database through Major's connectors. Agents reach them through a credential proxy that scopes credentials to the run, so no agent holds a standing broad key.
The app that holds state: when an agent works out a repeatable step, it builds an app for it. The app has typed inputs, a managed database, and its own logs. From then on the agent runs the app instead of reasoning through the step again.
The agent and its judgment: the agent keeps the decisions that need judgment, such as whether a change looks wrong or an exception deserves escalation. The model does less, not nothing.
Identity: shared agents run as the invoking user, so Salesforce and other upstream systems see that user's scoped identity.
Trigger and approvals: a workflow runs the app on a schedule or an event. Restricted actions pause for a named person's approval in Slack before they commit.
Audit and rollback: every action lands in the app's logs, exportable to a SIEM, and apps are version-pinned so you can reconstruct behavior and roll back.

Start building on Major and the controls come with the apps rather than being added afterward.

What we believe, and what this does not solve

Governance has to be structural. When the repeatable work is code with permissions and logs, it is inspectable by default. When it is re-reasoned inside a model on every run, you are auditing a black box. Reason once. Run forever.

Run-as-invoker identity, query-layer RBAC, and exportable audit cover identity, logging, and containment. They do not cover model-level failures such as prompt injection or hallucination, data governance, or the human decision about which actions need approval. Those need their own guardrails and owners.

If you are standing up agent governance, ask your next vendor whether identity, audit, and containment are enforced at the query layer or only described in a policy.

Start building on Major

Run your first governed agent workflow on Major, with run-as-invoker identity, query-layer RBAC, and an exportable audit trail on every action it takes.

Frequently asked questions

How do you govern AI agents?: Govern agents at three points: authenticate the agent and scope its permissions to the task, keep a durable log of every action it takes, and set containment boundaries on what it can do autonomously. Each has to be enforced where the action happens, at the query layer, rather than described in a policy document. Major applies all three at the app layer, where agents act through deterministic apps with scoped credentials and role-based access checked before the write commits.
What is the NIST AI RMF?: The NIST AI Risk Management Framework (AI RMF 1.0, NIST.AI.100-1) is the US baseline framework for managing AI risk, released in January 2023 and being revised. It organizes the work into four functions: Govern, Map, Measure, and Manage. It defines what trustworthy AI requires without prescribing an implementation, so enforcement is left to the adopting organization.
Does the EU AI Act require audit logs?: Yes. Article 12 (Record-keeping) requires that high-risk AI systems technically allow for the automatic recording of events, logs, over the lifetime of the system. The logs must support identifying risks and monitoring how the system operates. That record is easiest to produce when the agent's work runs as a deterministic app, which is how Major logs each agent action and exports it to a SIEM.
What is the difference between AI governance policy and enforcement?: Policy states intent: who should be allowed to do what, what should be logged, where autonomy should stop. Enforcement applies that intent at the point of action so it cannot be bypassed. A permission described in a document but never checked at the query is a preference. A permission checked by the system before the action commits is a control.
How do you audit what an AI agent did?: Audit the actions rather than the prompts: for each step, record which identity authorized it, which system it touched, what it changed, and the result, in a store the agent cannot quietly edit. A trace of prompts and completions debugs the model but will not tell an auditor what changed in Salesforce at 14:32. On Major, that entry is written where the agent acts and is exportable to your SIEM.