Permissions, Approvals, and Audit: The Rules of a Trustworthy AI Agent

Last updated: September 26, 2026. This article describes the practices and sources available as of this date. The section covering 2027 contains planning scenarios, not guaranteed predictions. The legal information is general and does not replace an analysis tailored to the specific situation.

An AI agent truly becomes useful when it doesn’t just generate a response, but can consult apps, modify records, send messages, or initiate processes. Yet, at that very moment, a question arises that many pilot projects tend to postpone: on whose behalf is the agent acting, what is it allowed to do, and how can we later prove what happened?

For an SME, the answer shouldn’t be a cumbersome corporate infrastructure. What's needed is a proportional set of controls, applied in the right places. The language model can interpret a request and suggest the next step, but it shouldn’t be the sole component deciding whether that step is authorized. Permissions, approvals, and logging must be enforced through code, identity, and policies that operate outside the model.

This guide explains a practical architecture for AI agents working with email, CRM, documents, invoices, websites, or infrastructure. It makes no promise of zero risk, nor does it present human approval as a universal solution. The goal is more realistic: to limit the impact of an error, to block unauthorized actions before execution, and to enable event reconstruction without turning the log into another sensitive database.

Executive summary

A trustworthy agent needs six qualities:

1. Distinct identity and user assignment: the system must distinguish the agent, the person who initiated the task, and the service executing the action.
2. Minimal privileges: the agent receives only the tools, operations, data, and environments required for the current task.
3. Authorization for each significant effect: checks occur when the agent tries to use the tool, not just at login or at the start of the conversation.
4. Approvals proportional to risk: routine reads may be automated, while publishing, payments, deletions, or data transfers require explicit confirmation or dual control.
5. End-to-end audit: every action must be linked to the original request, identities, applied policy, approvals, and actual outcome.
6. Revocation and stop capability: access should expire, be quickly revocable, and there must be a way to halt executions in progress.

These principles aren’t tied to any particular model or provider. They adapt established access control and zero trust architecture practices to the specifics of AI agents: dynamic plans, tool calls, untrusted external content, delegation, and the ability to have effects across multiple systems.

Why an agent shouldn’t be treated as a mere chatbot

A chatbot usually generates text that a person reads before using. An agent can follow a much longer loop:

1. receives an objective;
2. consults data or documents;
3. decides which tool to use;
4. performs an action;
5. observes the result;
6. continues until it determines the objective has been reached.

The risk isn’t just from a wrong answer. It can stem from a correctly executed, but inappropriate, action: an email sent to the wrong recipient, a discount applied to an ineligible client, a record deleted, a confidential file uploaded to an external service, or a command run in production.

Research confirms this isn’t just a theoretical issue. ToolEmu built scenarios for high-stakes tools and identified failures with potential financial or privacy consequences. AgentDojo evaluates agents using tools on untrusted external data and shows that prompt injection attacks can divert the agent’s actions. These results don’t provide a universal risk rate for every implementation, but do illustrate why a well-crafted prompt can’t substitute for technical controls.

The design rule is simple:

The model proposes. Policy authorizes. The tool executes. The log proves.

Five concepts that are often confused

Authentication

Authentication answers the question “who is this?”. In an agentic commerce flow, multiple identities may coexist at the same time:

• the user who made the request;
• the agent or its execution instance;
• the application orchestrating the process;
• the technical account used to access an API;
• the person who approves a sensitive action.

If all appear in the log under the same generic account, it becomes impossible to determine responsibility.

Authorization

Authorization answers the question “what can this identity do with this resource, in this context?”. It’s not enough for the agent to have access to the CRM. The policy must be able to distinguish between reading a contact, modifying it, exporting a list, and deleting a record.

Delegation

Delegation means a person or service grants the agent limited authority for a task. Delegated authority shouldn’t exceed that of the person and shouldn’t be automatically passed on to a subagent without explicit boundaries.

Approval

Approval is a one-time decision regarding a specific action. It does not replace authorization. An interface that asks the user to approve a payment must not allow the payment if the user did not already have the right to do it.

Audit

Audit is the ability to reconstruct who requested, what the system decided, what policy was applied, what was executed, and with what result. Audit is not the same as real-time monitoring, nor is it full storage of conversations.

The technology snapshot as of September 26, 2026

The basic principles are mature, but identity and delegation for agents are still an emerging area. In February 2026, NIST published a conceptual document on the identity and authorization of software and AI agents. Its status is that of a conceptual document, not a final standard. However, it shows that the industry is trying to apply well-known identity and access management practices to agents, instead of inventing separate security for each platform.

NIST Zero Trust Architecture formulates a relevant principle: access is decided for each request, with least privilege, and no implicit trust based solely on network position. NIST SP 800-53 Rev. 5 offers established control families for access, least privilege, identification, audit, and log protection. These publications are not recipes dedicated exclusively to agents, but they form a solid foundation.

In the agentic area, OWASP Top 10 for Agentic Applications 2026 and the guide Agentic AI Threats and Mitigations cover risks such as goal redirection, tool abuse, identity and privileges, contaminated memory, and cascading failures. Published on September 1, 2026, OWASP Agent Control Standard proposes control points and declarative policies enforced during execution, but it is a new open standard, not an automatic guarantee that an implementation is secure. Current OpenAI documentation on guardrails and approvals recommends placing checks at the boundary of the tool producing the effect. Google Cloud describes dedicated identities, least privileges, deny policies, and human-approval modes for MCP tools.

The practical 2026 conclusion is that there’s no single product that will automatically turn an agent into a trustworthy system. Control relies on a combination of identity, policy, isolation, approvals, logging, and testing.

The permission model: more precise than “read” and “write”

A useful permission for agents must be described along multiple axes:

A generic role like admin does not express these limits. Nor does a broad scope like crm.write suffice for an agent who only needs to update a lead's status.

Separate identity for each relevant agent

Avoid shared technical accounts used by multiple agents. A distinct identity allows:

• revoking a single agent without disrupting all automations;
• different policies for sales, support, and finance;
• precise tracking of actions;
• detecting an agent behaving unusually;
• independent rotation and expiration of credentials.

An agent’s identity should not conceal the user. In a delegated flow, the log should retain both the agent’s identity and the user or process on whose behalf it acts.

Short-lived credentials, kept out of prompt

API keys, access tokens, and passwords must not be entered into the prompt, memory, or documents accessed by the model. A gateway, vault, or even a simple internal service can attach the credential only after the policy has approved the call.

Technical preferences are:

• short-lived tokens;
• audience validated for the destination service;
• the narrowest possible scopes;
• automatic rotation;
• centralized revocation;
• no passing the received token to another service.

RFC 9700 brings together current OAuth 2.0 security practices, while RFC 9396 allows for authorization descriptions more detailed than a simple list of scopes. Not every SME must implement these protocols themselves, but the chosen provider should be able to explain token audience, expiration, revocation, and privilege limitation.

Authorize at the tool, not in the model’s prompt

The phrase “don’t delete anything without approval” in the prompt is useful as guidance, but it is not a security barrier. A prompt injection attack, a planning error, or an ambiguous context could cause the model to ignore or misinterpret it.

The control must be repeated right before the operation:

1. the agent proposes the tool call and arguments;
2. a policy enforcement point checks identity, resource, operation, and context;
3. the policy allows, denies, or requests approval;
4. the necessary credential is attached only after the decision;
5. the tool revalidates the right to the resource;
6. the result is logged.

This double verification prevents situations where the orchestrator approves an action, but the API executes it with an unrestricted technical account.

Separation of reading from writing and planning from execution

An agent analyzing invoices does not automatically need the right to pay them. An agent drafting an article should not be able to publish it by default. Separation can be by different tools, identities, or steps in the flow.

For sensitive tasks, a two-step model is useful:

• planning: the agent reads, analyzes, and generates a structured proposal;
• execution: a deterministic service validates the proposal and carries out only the approved operations.

The model does not get direct access to the database if a narrow function such as actualizeaza_status_comanda(id, status_permis), is sufficient.

Approvals: where they help and where they become security theater

Not every call requires human intervention. If a person must confirm every read, the system becomes slow and people learn to hit “Approve” without checking. This is approval fatigue.

A practical classification can start from five questions:

1. Is the action reversible?
2. Does it affect money, production, reputation, or a person’s rights?
3. Does it send data outside the organization?
4. Is the volume or value unusual?
5. Has the agent successfully performed this operation-context combination before?

Indicative control matrix

This is a starting matrix, not a legal classification. Thresholds must be adapted to the company, process, and actual consequences.

What the approver needs to see

A proper approval doesn’t ask for confirmation of a vague intent like “the agent wants to proceed.” The interface must show:

• the exact action;
• the system and target resource;
• fields changing, before and after;
• the recipient and data leaving the organization;
• amount, currency, and beneficiary, if money is involved;
• operational reason and the initial request;
• risks or rules that triggered the approval;
• the period for which the approval is valid.

Approval should be cryptographically or uniquely tied to the specific action. If the agent alters the recipient, amount, or attachment after approval, the previous approval is no longer valid.

When dual control is needed

The four eyes principle suits high-impact actions: payments above a threshold, vendor account changes, large-scale data exports, privileged production changes, or irreversible deletions. The second person should have the appropriate role and not be the same identity as the requester.

Expiration, denial, and unavailability

An approval request should expire. If the policy or approval service is unavailable, sensitive actions should safely fail, not execute by default. Denials must be returned to the agent as a clear final state, to prevent resubmitting the same action until it passes control.

What the audit log should contain

A useful log answers questions, not just accumulates text. For each run and important call, it’s recommended to have:

• a unique run identifier and an inter-system correlation ID;
• initiating user, agent, orchestrator, and executing service;
• the declared purpose and the reference to the ticket, order, or process;
• the agent configuration's model and version;
• the tool, operation, and target resource;
• the relevant arguments, redacted or pseudonymized where necessary;
• the source of external data used for the decision, identified by ID, version, or hash;
• the policy version and the rule that allowed, denied, or escalated the call;
• the approver, time, decision, and the exact approved item;
• the tool's result, status code, and resulting effect;
• the repeated attempts, cancellations, and compensation operations;
• the duration, consumption, and cost, if relevant for detecting abuse.

For distributed workflows, OpenTelemetry provides tracing conventions that can connect agent invocation, model calls, and tool executions. These technical traces must be enriched with policy decisions and business approvals. A simple performance trace is not automatically an audit log.

It is not necessary to store the model's “thoughts”

Auditability does not require keeping a complete internal reasoning. This may be unavailable, unstable, or may contain data we do not wish to retain. It is more useful to store:

• only the operational inputs strictly necessary;
• the plan or structured proposal presented to the policy system;
• the decision reason codes;
• tool invocations and their results;
• the evidence and versions of the relevant sources.

In this way, we can explain the observable process without treating model-generated text as either legal justification or absolute truth.

The log should not become a data leak

A log that retains tokens, passwords, full prompts, attachments, or unlimited personal data can create a bigger risk than the one it tries to reduce. EDPB materials on privacy risks with LLMs recommend access controls and logging, but also data minimization in logs.

Minimum practices:

• do not log secrets or tokens;
• mask sensitive fields;
• limit access to logs;
• define retention periods by category;
• protect log integrity and separate system administrators from audit administrators;
• document who can export or delete records;
• test whether an incident can be reconstructed before relying on these logs.

A suitable reference architecture for an SME

Not every element needs to be a separate product. What matters is the separation of responsibilities:

1. User interface authenticates the person and captures the purpose of the request.
2. The agent orchestrator plans steps and proposes tool calls.
3. The policy gateway check identity, action, arguments, environment, volume, and context.
4. Approval Service interrupts execution and collects a human decision when required by policy.
5. Credential Broker provides a limited token only after authorization.
6. Tool Adapter validates the schema and calls the destination API.
7. Audit and Monitoring System correlates the proposal, decision, and outcome.

Policy must be enforced in a component that the model cannot modify. If the agent can edit the file that defines its boundaries, control is only superficial.

Example of a clearly stated policy

The following rule is conceptual, not the syntax for any particular product:

• Agent: customer support.
• Action: updating a contact in the CRM.
• Allow if: the user has a support role, only the phone number or contact preference is changed, and the client is part of their portfolio.
• Limits: one record per call, in the production environment.
• Require approval if: a field classified as sensitive is changed.
• Deny if: the action involves deletion or external export.

The advantage of explicit policies is that they can be reviewed, tested, and versioned. The natural instruction from the prompt still guides behavior, but the deterministic policy decides authority.

Three practical examples

1. Agent for email and quoting

The agent reads a client's request, consults the catalog, and prepares a quote. A balanced configuration could allow automatically:

• reading the current conversation;
• consulting products and stock;
• creating a draft quote;
• saving the draft in the CRM.

It would require approval for:

• sending the external email;
• applying a discount beyond the threshold;
• attaching a document with personal data;
• adding a new recipient.

It would fully deny exporting the client database and changing banking details. The log would link the sent quote to the prices and discount policy in effect at that time.

2. Agent for invoices and payments

The agent can extract invoice data, verify the supplier, and prepare the payment. However, the right to read invoices does not imply the right to pay.

A secure workflow separates:

• the analysis agent, with read-only access;
• the deterministic validator for IBAN, duplicates, due date, and threshold;
• the approver;
• the payment service, with short-lived tokens and amount limits;
• subsequent reconciliation.

Changing the IBAN and making the first payment to a beneficiary should trigger an additional verification, not be learned automatically from an incoming email.

3. Agent for site administration

The agent researches and drafts an article in the CMS. Reading existing articles and saving a draft are reversible operations. Publishing, editing an already published article, and deleting an image have external impact.

Permissions can be separated as follows:

• read access to published content;
• create and update only one's own draft;
• no overwrite if the version has changed between reading and saving;
• publish only after editorial approval;
• deletion forbidden to the agent;
• log for sources, version, approver, and resulting URL.

This model prevents both accidental publication and the loss of changes made in the meantime by someone else.

MCP and tool authorization

Model Context Protocol standardizes how applications expose tools and resources to agents. The protocol does not remove the obligation to design permissions. An MCP server exposing a dangerous function with an overly broad token remains dangerous.

Current MCP documentation and SDKs are based on OAuth and protected resource metadata. Relevant practices include:

• validating that the token was issued for the respective server;
• rejecting token passthrough to downstream services;
• using limited scopes and increasing them only when the operation requires it;
• clear consent for clients and servers;
• HTTPS and strict redirect validation;
• separate credentials for external services;
• protection against the 'confused deputy' attack, where a service is tricked into using its authority on someone else's behalf.

MCP specification and guidelines must be checked at the time of implementation, as the protocol evolves. For an SME, the essential criterion is not just MCP compatibility, but the provider’s ability to restrict each tool and produce useful audit trails.

Testing before autonomy

An agent should not be promoted to production just for correctly completing a few demos. Testing must cover both success and denial.

Functional and policy testing

Explicitly check:

• operations permitted under normal conditions;
• operations denied for the wrong role;
• resources from another department or client;
• exceeding the volume or value threshold;
• token expiration and access revocation;
• modification of an action after approval;
• approver service unavailability;
• resuming a run after interruption;
• the accidental duplication of the same operation.

Adversarial tests

Insert in documents, emails, and test pages instructions meant to entice the agent to ignore its objective, disclose data, or use an alternate tool. The goal isn’t just to check if the model refuses. The essential verification is whether the authorization system blocks the effect, even when the model proposes an incorrect call.

Run these tests after changes to the model, prompts, tools, policies, or connectors. An old assessment does not guarantee how a new configuration will behave.

Shadow mode and gradual autonomy

Before live execution, the agent can operate in shadow mode: it proposes actions, and the system compares them to human decisions without producing any effects. The next stage allows the agent to carry out low-risk operations automatically, while keeping human approval for others. Autonomy is increased only based on observed data—not on the impression that a demo 'seems intelligent.'

Metrics that measure control, not just productivity

In addition to time saved and completion rate, track:

• the percentage of calls denied by policy;
• the percentage of actions that require approval;
• approval and denial rates by category;
• the wait time for approval;
• the number of actions modified after being presented to the approver;
• attempts to access outside the allowed scope;
• journal coverage for actions with effect;
• the number of credentials that are too broad or unused;
• the time required to revoke and stop the agent;
• incidents, near-misses, and compensated operations;
• the gap between shadow mode proposals and human decisions.

A very high approval rate doesn’t necessarily prove safety. It may indicate unnecessary approvals or fatigue. A very high denial rate can indicate a poorly configured agent or a policy incompatible with the process.

Legal and compliance aspects

Permissions and auditing are technical controls. They do not, on their own, establish the legality of processing or whether an AI system is subject to classification.

If the agent processes personal data, GDPR principles still apply: clearly defined purpose, data minimization, security, retention periods, and the operator’s ability to demonstrate compliance. The journal must be designed in line with these principles. Keeping everything 'for audit' without a clear purpose and timeline is not a prudent solution.

The European AI Regulation includes requirements for automatic log retention and human oversight for certain high-risk systems. These obligations do not automatically turn any internal agent into a high-risk system. Classification depends on the use, the role of the organization, and the context. Additionally, the timeline for applying certain rules for high-risk systems was revised and clarified in 2026. The European Commission maintains an updated page on the implementation of the AI Act..

For decisions affecting employees, lending, access to essential services, or other rights, a specific legal assessment is required. This article provides a technical framework, not legal advice.

Common mistakes

'The agent uses the administrator account, but the prompt says to be careful'

A prompt does not reduce the account’s privileges. If the agent is compromised or makes a mistake, the maximum impact is still that of an administrator.

'The user accepted access during installation'

Initial consent to an integration does not authorize any future action. Sensitive operations must be evaluated in their specific context.

'All actions require approval, so we’re safe'

Too many approvals create routine. Furthermore, a person can be misled by an incomplete description. The interface should show the exact effect, and the policy should block unauthorized operations regardless of superficial approval.

'We have the vendor’s logs'

Logs from a single vendor may show the model call, but not the full sequence between the user, orchestrator, policy, approval, and final API. Check for correlation identifiers and the ability to export.

'We keep all prompts for investigations'

This can record personal information, secrets, and full documents in the journal. Define the required fields, mask content, and keep references or hashes where the full text isn’t justified.

'A subagent automatically inherits all rights'

Chained delegation can amplify privileges and lose track of the initial user. Each subagent must receive a set of permissions at most equal to, and typically more restricted than, those of the main agent, tailored to their subtask.

“If the operation fails, the agent can try again”

Retrying without an idempotency key and without state-checking can cause duplicate payments, orders, or messages. Tools with side effects must distinguish a safe retry from a new operation.

Practical 30-day implementation plan

Week 1: inventory and classification

• list agents, tools, technical accounts, and owners;
• document accessible data and environments;
• classify operations by impact and reversibility;
• identify shared accounts and administrator privileges;
• define who can stop each agent.

Week 2: permissions and identity

• create separate identities for important agents;
• separate read, write, publish, and delete actions;
• move secrets out of chat prompts and memory;
• introduce short-lived tokens or rotate credentials;
• limit resources, environments, volumes, and destinations.

Week 3: approvals and audit

• define the risk matrix and thresholds;
• implement interruption before the effect, not after;
• show the concrete difference and recipient to the approver;
• add correlation IDs and policy version;
• redact sensitive data from logs;
• test export and replayability of a run.

Week 4: testing and gradual rollout

• run allowed, denied, and adverse cases;
• test revocation, expiration, and unavailability;
• start in shadow mode or only with reversible operations;
• analyze approvals for signs of fatigue;
• establish monthly reviews of privileges and incidents;
• document criteria for increased autonomy.

What might change in 2027

The following are plausible scenarios, not certainties.

Better-standardized agent identities

NIST initiatives and evolving cloud platforms signal the potential for workload identities dedicated to agents, with improved delegation and traceability. We are likely to see closer integration between agent registries, IAM, gateways, and policy systems.

Finer-grained and temporary authorization

Instead of static, broad scopes, platforms may increase the use of on-demand authorization, limited by action, resource, amount, and time window. This would reduce permanent credentials, but may increase complexity and reliance on central services.

Policy-assisted approvals and separate models

Moderate-risk operations could be automatically assessed by a policy engine plus a separate control model. However, 2026 research shows that model-based monitors can themselves be bypassed. Therefore, such an evaluator should not replace deterministic barriers for critical operations.

Interoperable audit across multiple agents

As tasks move between agents and organizations, portable evidence of delegation, policy, and outcomes will be needed. Observability conventions help, but there is still no universal solution for non-repudiation and full provenance in agentic commerce workflows.

For an SME, the healthiest strategy is to use existing standards, avoid lock-in to a proprietary format, and maintain control over identities, policies, and essential logs.

Checklist before granting real access

• Does the agent have a distinct identity?
• Can we identify the person or process on whose behalf it operates?
• Are permissions limited by operation, resource, environment, time, and volume?
• Are secrets kept out of the prompt, memory, and log?
• Is policy enforced outside the model, even before the tool?
• Do publication, payment, deletion, and external transmission have clear thresholds?
• Does the approver see the exact effect, not just a generic description?
• Does approval expire and become invalid if the action changes?
• Can we revoke access and stop active runs?
• Are repeated operations idempotent?
• Does the log link the request, policy, approval, and result?
• Are logs minimized, protected, and have a set retention period?
• Have we tested attacks using external data and rejection handling?
• Is there an owner, incident procedure, and periodic review?

Conclusion

Trust in an AI agent should not be measured by how convincingly it explains what it intends to do. It must be built upon verifiable boundaries.

A trustworthy agent is not one to whom we grant unlimited access simply because the model appears capable. It’s an agent that can work efficiently within a clear perimeter, uses temporary authority, seeks proper approval before taking action, and leaves sufficient evidence for verification. If an error or an attack occurs, the architecture limits the damage and allows intervention.

For most SMEs, the first step is not acquiring a complex platform. It’s inventorying actions, separating read from write, removing administrative accounts from automated flows, and defining three categories: what the agent can do alone, what requires approval, and what is never permitted.

Sources and recommended reading

• NIST AI Risk Management Framework
• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-53 Rev. 5, Security and Privacy Controls
• NIST NCCoE, Software and AI Agent Identity and Authorization, concept document from 2026
• NIST IR 8596, Cybersecurity Framework Profile for Artificial Intelligence, initial 2025 draft
• OWASP Top 10 for Agentic Applications 2026
• OWASP Agent Control Standard, published September 1st, 2026
• OWASP Agentic AI Threats and Mitigations
• OpenAI, Guardrails and human review
• Google Cloud, AI security and safety for MCP servers
• Google Cloud, Agent Identity overview
• Model Context Protocol, Authorization, revision 2026-07-28
• RFC 9700, Best Current Practice for OAuth 2.0 Security
• RFC 9396, OAuth 2.0 Rich Authorization Requests
• OpenTelemetry, GenAI observability
• AgentDojo, agent attack benchmarking
• ToolEmu, agent risk assessment with tools
• Regulation (EU) 2024/1689 on artificial intelligence
• European Commission, AI Act enforcement framework
• EDPB, AI Privacy Risks & Mitigations in Large Language Models