AI Agent Access Control and Audit Logs: A Practical Guide

The short answer: what is AI Agent access control?

AI Agent access control defines, for each agent, which data it may read, which tools it may call, which actions it may take on its own and which actions must wait for a person to approve. An audit log is the record that lets you answer later: which agent, acting for whom, did what, when, based on which data, and who approved it.

The two belong together. Permissions limit the damage when an agent misreads a request or is manipulated; logs let you detect, investigate and show customers, partners or regulators that people remain in control of the system.

This guide is for operations, IT and legal leads who are putting AI Agents into real workflows. It draws on public guidance from OWASP and NIST, and on the relevant provisions of Vietnam's 2025 Law on Artificial Intelligence and 2025 Law on Personal Data Protection.

Why AI Agents need their own approach to permissions

A chatbot only answers in text. An AI Agent calls tools: it looks up the CRM, edits orders, sends messages, creates accounts. Once it can act, a wrong answer can become a wrong operation on real data.

The OWASP Top 10 for LLM Applications (2025) calls this risk Excessive Agency (LLM06): damaging actions performed in response to unexpected, ambiguous or manipulated model outputs, whatever the cause of the malfunction. OWASP names three common root causes: too much functionality, too many permissions, or too much autonomy over high-impact actions.

The cause of a bad output might be a poorly written prompt, a weak model, or malicious instructions hidden in an email or document the agent reads (see What is prompt injection). You cannot remove all of these causes, so the practical answer is to narrow what an agent can do when it gets things wrong.

• Too much functionality: the agent only needs to read email to summarise it, but its tool can also send and delete messages.
• Too many permissions: the tool only needs to read a product table, but connects with a database account that can modify and delete every table.
• Too much autonomy: the agent deletes documents or publishes content without asking the user first.

Step 1: give every AI Agent its own identity

A common mistake is letting an agent run under an employee's account or a shared admin account. The log then says "account X edited the order" with no way to tell whether a person or the agent did it, and you cannot revoke the agent's access without affecting the person.

OWASP recommends tracking user authorization so that actions taken on behalf of a user run in that specific user's context with the minimum privileges necessary, rather than through a generic high-privileged identity.

Step 2: choose a permission model, RBAC or ABAC

RBAC (role-based access control) attaches permissions to roles, then assigns roles to people or agents. Most business software already works this way, and business teams find it easy to understand.

ABAC (attribute-based access control) is defined by NIST in SP 800-162 as a method where authorization is determined by evaluating attributes of the subject, the object, the requested operation and, in some cases, environment conditions against policy or rules. For AI Agents, ABAC helps when permission depends on context: amount, branch, data sensitivity, working hours.

In practice many organizations combine them: RBAC decides which role an agent has, and ABAC adds conditions for sensitive operations.

Step 3: scoped tokens and checks in the downstream system

The token or API key an agent uses is its permission. If the token can read the whole CRM, the agent can technically export the whole CRM, whatever the system prompt says.

OWASP stresses two points: give the agent only the tools it actually needs, and enforce authorization in downstream systems rather than relying on the model to decide whether an action is allowed. Every request that goes through a tool should be checked against security policy.

• Split permissions by verb: read, draft, write, send externally, delete. A summarising agent only needs read.
• Prefer narrow tools such as "create support ticket" over open-ended ones such as "run any command" or "fetch any URL".
• Use short-lived tokens issued per task where possible, and revoke them when the task ends.
• Never put API keys in prompts or documents the agent reads; keep them in your infrastructure's secret store.
• Rate-limit tools that change things (sending messages, editing data) to contain damage if an agent misfires in bulk.

Step 4: approval gates for irreversible actions

OWASP recommends human-in-the-loop control so that a person approves high-impact actions before they are taken. Build the gate into the tool that executes the action (for example, a "publish" tool that always waits for a person to approve), not just as a line in the prompt.

Vietnam's Law on Artificial Intelligence No. 134/2025/QH15, in force from 1 March 2026, sets out in Article 4(2) the principle that AI serves people and does not replace human authority and responsibility, and that human control and the ability to intervene in AI decisions and behaviour must be maintained. Article 7(4) prohibits obstructing, disabling or distorting the mechanisms for human supervision, intervention and control. See our analysis of the 2025 AI Law.

Approvers need enough to decide: the original request, the data the agent used, the proposed action and what remains uncertain. A lone "Approve" button tends to turn approval into a formality. Gate design is covered in more depth in Human-in-the-loop.

Step 5: what an audit log should record

The OWASP Developer Guide asks that each log entry carry enough metadata (when, where, who, what) to reconstruct the timeline of an event, including timestamp, severity, account identity, trace ID, outcome and description. For AI Agents, add the tool calls and the approval.

How much content to log is a balance. OWASP warns against logging too much or too little, and its Logging Vocabulary advises avoiding full prompts and tool inputs and outputs, preferring usage measures, policy thresholds, request identifiers and the tool or model involved. If you must keep content for investigations, mask personal data and keep it for a shorter period than the metadata.

Log retention and personal data

AI Agent logs will almost certainly contain personal data: customer names, message content, employee IDs. OWASP also notes that logs may contain personal and other sensitive information, and must be protected from unauthorized access, modification and deletion.

Vietnam's Law on Personal Data Protection No. 91/2025/QH15, in force from 1 January 2026 (with implementing Decree 356/2025/ND-CP, which replaces Decree 13/2023/ND-CP), states in Article 3(3) that personal data is stored for a period appropriate to the purpose of processing, unless the law provides otherwise. Article 14 lists when personal data is deleted or destroyed, including when the processing purpose has been fulfilled and when the legal retention period has expired. See the full checklist in our 2025 Personal Data Protection Law guide.

In short, you need a retention policy with reasons, not "keep everything just in case".

• Define the purpose of each log type: incident investigation, business reconciliation, proof of approval.
• Set separate retention periods for metadata and detailed content; keep the part with personal data shorter unless sector rules require longer.
• Mask or encrypt sensitive fields; limit who can see full logs.
• Delete on expiry through a recorded process, including in rotating backups.

Tamper-evident logs, explained plainly

A log is only worth something if readers trust it was not edited after the fact. OWASP Top 10:2025 recommends that every transaction has an audit trail with integrity controls against tampering or deletion, such as append-only database tables.

Think of the log as a bound notebook with numbered pages. You can add new pages, but tearing out or rewriting an old page leaves a mark. Common techniques are:

• Append-only: the application and agent accounts cannot edit or delete earlier entries.
• Chained fingerprints: each entry includes a hash (a digital fingerprint) of the previous entry. Changing an old entry breaks the chain after it, so the change is detectable.
• Separate storage: ship logs to a store that the application's own administrators cannot quietly delete from.
• Alert when logging stops: OWASP recommends processes to detect that logging has stopped and to spot unauthorized access or deletion.
• Never give an agent a tool to read all logs or modify its own log.

Implementation checklist and how EYC works

You do not need a large platform to start. Most of the steps below can be done with the identity system, database and log store you already have.

• Keep an AI Agent register: purpose, owner, systems accessed, permission level.
• One service account per agent; never share a human account.
• Use RBAC for roles and add ABAC conditions for operations with limits.
• Narrow, short-lived tokens; permissions checked in the downstream system.
• Tier actions; build approval gates into the tools for irreversible actions.
• Logs with who, what, when, input, output, tool call and approval.
• Purpose-based retention; mask personal data.
• Append-only, separately stored logs with an alert when logging stops.
• Review agent permissions and rehearse revoking agent access regularly.