AI agent governance: access scopes, approvals and audit logs

What is AI agent governance?#

AI agent governance is the set of owners, rules and technical controls that decide which company systems an AI agent may reach, under which identity and scopes, which of its actions need a person to approve them, what gets logged, how long those logs are kept, and what is never in scope. It applies whether the agent is a vendor copilot, an internal build or an assistant connected through MCP.

It is narrower than AI governance as a whole. The NIST AI Risk Management Framework treats Govern as a cross-cutting function covering policies, roles, inventories and third-party risk for every AI system. Agent governance is the part of that program that turns policy into permissions: the scopes on a token, the deny rules in an agent runtime, the approval step in front of a refund.

It is also different from data governance for a licensing decision, which decides who approves releasing a copy of records to an outside developer, and from governance tooling, which records where data lives and moves. Those questions are covered in separate guides linked at the end. This page is about the live access an agent has to your systems of record.

Why does an agent need different controls from a person or an app?#

An agent needs its own controls because it decides at run time which tools to call, and that decision can be steered by the content it reads. OWASP's guidance for LLM applications calls the resulting risk Excessive Agency and traces it to three root causes: excessive functionality, excessive permissions and excessive autonomy.

A person with CRM access will not obey an instruction hidden in a support ticket. An agent might, which is why OWASP's Top 10 for Agentic Applications, published in December 2025, lists agent goal hijack, tool misuse, and identity and privilege abuse as separate risks. A conventional integration also behaves predictably: it calls the same endpoints every night. An agent with the same credentials can combine them in ways nobody tested.

Two design rules follow. First, enforce authorization in the downstream system, not in the prompt; OWASP calls this complete mediation. Second, act in the context of the user the agent works for, with the minimum privileges needed, rather than through one shared high-privilege account. On the token side, the MCP specification requires servers to accept only tokens issued for them and forbids passing a client's token through to upstream APIs.

The agent access control sheet: one row per system#

The access control sheet is one table, filled per system, that records the agent's default scope, what triggers a human approval, what the log captures and for how long, and what is excluded. Fill it before the first connection and attach it to the approval for that agent. The rows below are a starting template for common business systems; replace the examples with your own objects and fields.

How should you set an agent's scopes?#

Set scopes by starting from nothing and adding the narrowest access each task needs, which is the NIST definition of least privilege applied to a process acting on a user's behalf. In practice that means five tiers, assigned per system and written into the control sheet.

Grant the tier through the system's own permission model, such as a dedicated integration user, a permission set or an OAuth scope, not through instructions to the agent. Under the MCP authorization model, a client should request only the scopes it needs, and a server can answer a call that needs more with an insufficient_scope error, so extra access is asked for at the moment it is needed rather than granted up front.

Then narrow again inside the agent runtime. Agent frameworks let you deny tools outright. In the Claude Agent SDK, a matching deny rule blocks a tool even in its most permissive mode, and a dontAsk mode turns every unplanned request into a denial, which suits a headless agent with a fixed tool list. Do not rely on a tool's self-description: the MCP specification treats annotations such as readOnlyHint as untrusted hints unless the server itself is trusted.

• 1Tier 0, metadata only: object names, field lists, record counts and date ranges, no record contents. Use it for discovery and scoping.
• 2Tier 1, read records: contents of named objects the acting user can already see.
• 3Tier 2, draft: the agent writes to a draft, staging table or suggestion that a person publishes.
• 4Tier 3, write with approval: the agent changes a system of record only after a named approver says yes.
• 5Tier 4, never: listed in the exclusion column, enforced by a deny rule and by the system's own permissions.

Which agent actions should need human approval?#

Require approval for actions that are hard to reverse, that leave the company, or that change who can access what. The MCP specification says there should always be a human able to deny tool invocations and that clients should prompt for confirmation on sensitive operations; OWASP recommends human approval of high-impact actions, implemented in the downstream system or the tool itself.

Agent frameworks now make this a declared property of a tool. The OpenAI Agents SDK lets a tool set needs_approval, pauses the run until a person approves or rejects the call, and falls back to manual approval when a rule cannot safely read the arguments. That fail-closed behavior is the right default to ask any vendor about.

Keep the trigger list short. If every read needs a click, approvers stop reading. Approve categories of action, record each decision, and review the approval log monthly for anything approved too quickly or too often.

• 1Money: payments, refunds, credits, price changes, vendor bank details.
• 2External communication: emails, chat replies, social posts, notifications to customers or suppliers.
• 3Deletion and bulk change: deletes, merges, mass updates above a set record count.
• 4Access change: sharing links, role or permission edits, new connections, new scopes requested at run time.
• 5Data leaving: exports, file downloads to a new location, any copy to a system outside the approved list.
• 6First use: the first call to any tool the agent has not used under this approval.

What should an agent audit log record, and how long should you keep it?#

An agent audit log should let you reconstruct who acted, for whom, through which tool, on which records, with whose approval, and with what result, without storing a second copy of the records themselves. The MCP specification asks clients to log tool usage for audit; OWASP adds that logging limits damage even though it does not prevent it.

Watch the default payload. OpenAI's Agents SDK tracing is on by default and records the inputs and outputs of model calls and function calls unless trace_include_sensitive_data is turned off. That is useful while testing and risky in production, because the trace store becomes a new archive of customer and employee data with its own access and retention questions.

Set retention per log type, and check the platform default before you assume one. In Microsoft Purview, for example, Audit (Standard) records are kept for 180 days by default, Premium records for Exchange, SharePoint, OneDrive and Microsoft Entra ID one year for suitably licensed users, and records of non-user entities such as service principals a fixed one year. If your incident review, financial audit or contract terms need longer, configure it. Counsel should confirm periods set by law or contract.

• 1Agent identity and version, plus the human sponsor.
• 2Acting user or service context, and the scopes on the token used.
• 3Tool or MCP server called, and the action.
• 4Record identifiers read or changed, not full record bodies.
• 5Parameters, redacted or hashed where they contain personal data.
• 6Approval ID, approver and decision time for gated actions.
• 7Result: success, error, denied by policy, rejected by approver.
• 8Session or trace ID linking every step of one task.

What should stay out of an agent's reach?#

Some records should stay out of an agent's reach regardless of how useful they would be, either because the risk of a wrong action is too high or because your obligations to others do not allow it. Put them in the exclusion column, enforce them with deny rules and system permissions, and review the list whenever a new system is connected.

Exclusions protect against two different failures. One is the agent doing something harmful with access it should not have. The other is the agent's vendor receiving data your contracts or privacy notices do not permit you to share with that vendor. Access permissions answer the first; your contracts, notices and counsel answer the second.

• 1Credentials, API keys, secrets and bank login details anywhere they are stored.
• 2Payment card data and full bank account numbers.
• 3Health, disability, background check and other sensitive employee records.
• 4Compensation and payroll detail.
• 5Legally privileged files, litigation folders and anything under a legal hold, for writes at minimum.
• 6Board, M&A and investor materials.
• 7Customer data whose contract forbids processing by new subprocessors or AI vendors.
• 8Systems belonging to clients, partners or acquired entities not covered by the approval.

Who owns agent governance, and how often is access reviewed?#

Give every agent a named human sponsor who is accountable for its purpose, its access and its retirement, separate from the engineer who configures it. Microsoft Entra ID Governance, whose agent governance features Microsoft labels as preview, builds this into agent identities: sponsors are accountable for lifecycle decisions and access reviews, access package assignments can expire unless the sponsor extends them, and sponsorship passes to the sponsor's manager when the sponsor leaves.

The NIST AI RMF asks for the same structure in tool-neutral terms: an inventory of AI systems (GOVERN 1.6), defined human roles for overseeing them (GOVERN 3.2), and policies for third-party AI risk (GOVERN 6.1). For agents, the inventory row is the control sheet.

Review access on a fixed cycle, quarterly for most agents and at every change of vendor, model, MCP server or use case. Remove scopes nobody used in the period. Retire an agent the way you would offboard an employee: revoke tokens, delete its integration user, and keep its logs for the retention period.

How does agent access relate to licensing your data?#

Giving an agent access to your systems is not the same as licensing your data. An agent reads records live, for your own work, under your permissions. Licensing delivers a defined, prepared copy to an outside developer under a contract that limits its use. A connection or OAuth approval does not by itself grant a vendor rights to train on what the agent reads; whether a vendor may retain or reuse that data depends on its terms, which counsel should review.

The governance work overlaps in useful ways. The control sheet is also an inventory of which systems hold which records, and clean audit logs show what has already been shared and with whom. Both help when a licensing question comes up later.

SourceX is the enterprise data transaction layer for AI: it runs rights review, contracting, data preparation, delivery and payment for businesses licensing operational data to AI developers. The company approves exactly what is released, once per deal, and sees what would leave before anything is shared. That is a separate decision from any agent connection, made through a contract rather than a token.