AI Agent Security: Permissions, Tools and Human Review

Define authority before giving an agent tools

Generic threat lists are useful, but they do not answer the buyer’s question: what authority can this agent safely hold on day one?

Start with the workflow, not the model or platform. An agent that summarizes account notes has a different security boundary from one that sends customer emails, changes CRM stages, releases payments, executes code, or browses the open web. The same model may support each task; the authorization design should not be the same.

A practical rule:

• Keep an agent read-only when it handles sensitive data, ambiguous source material, or a process without a reliable baseline.
• Use draft-only when output is customer-visible, financially meaningful, or likely to create cleanup work.
• Allow limited write access only for narrow, reversible actions with a documented owner, action allowlist, and tested rollback.
• Reserve autonomous write access for stable, high-volume, low-blast-radius actions where exceptions are rare and containment is proven.

This is why the business case and security model are inseparable. A broad agent with broad human-equivalent access may look efficient in a demo, but its exception and review cost can erase the operational gain. A constrained agent that produces a useful queue, recommendation, or approved draft can change the workflow without asking the organization to accept uncontrolled autonomy.

Score the workflow before granting write access

Use the following scorecard before selecting a vendor, framework, or implementation path. Score each dimension from 0 to 2, where 0 is low risk and 2 is high risk.

Add the six scores.

Two disqualifiers override the total score:

1. Do not launch autonomous write access when high blast radius is combined with sensitive data or an external effect.
2. Do not launch autonomous write access for browser or code-capable agents that can reach localhost or privileged internal services without explicit authentication, network restrictions, and environment separation.

The score is a planning tool, not a compliance certification. Its purpose is to make a decision visible: reducing authority is often the fastest way to make a valuable pilot acceptable.

Planning an implementation? See what an Arsum build can include →

A worked example: finance exception agent

Consider an agent that reviews invoice exceptions. It can read invoice metadata, purchase-order references, approved vendor records, and the related email thread. Its job is to explain why an invoice does not match and prepare a recommendation for an accounts-payable reviewer.

This is a useful pilot because it has a bounded action space. It should not begin by changing payment instructions, creating vendors, or releasing payments.

Proposed launch design

Its illustrative score is 9: blast radius 2, reversibility 1, sensitivity 2, external effect 1, exception rate 2, runtime exposure 1. That score supports draft-only operation, not autonomous action.

Pilot acceptance gate

Set acceptance criteria before the pilot begins. The figures below are placeholders to complete with your own baseline, not expected results.

Promotion from draft-only to limited write access should require evidence, not confidence. The workflow owner should show that the action is reversible, the allowed fields are narrow, review feedback has stabilized, audit records are complete, and the rollback test works. If any of those conditions fail, keep the agent in draft-only mode or reduce its scope.

Controls that protect the workflow

The OWASP AI Agent Security Cheat Sheet identifies agent-specific risks including tool abuse, privilege escalation, memory poisoning, excessive autonomy, high-impact action abuse, denial of wallet, and supply-chain risk. Its guidance supports least-privilege tooling and approval for sensitive actions. The operational inference here is that controls should sit around the workflow’s tools and identities, not only in its prompt.

Treat untrusted content as data, not instructions

Customer emails, tickets, PDFs, web pages, retrieved documents, and tool outputs can all contain content that attempts to influence an agent. Do not rely on a prompt asking the model to ignore hostile instructions as the control.

Instead:

• Separate untrusted content from the policy and authorization layer.
• Give tools explicit parameters and server-side validation.
• Check every requested action against an allowlist, scope, value limit, and approval rule.
• Restrict outbound destinations and log external calls.
• Route suspicious or conflicting evidence to a human queue rather than asking the agent to resolve it.

Prompt injection is a major design risk for agents that consume untrusted content. It is not a reason to abandon useful workflows; it is a reason not to let content decide what tools the agent may use.

Use a workflow-specific service identity

Never copy a human operator’s broad permissions into an agent integration. Create a service role for the one workflow:

• Read only the tables, folders, fields, and accounts required.
• Use short-lived, scoped credentials where the connected system supports them.
• Separate development, staging, and production identities.
• Deny tool calls outside the allowed action set.
• Require a separate approval identity for consequential actions.

If a task needs broad permissions to be useful, that is usually a sign to split it into smaller agents or keep it human-approved. This architecture decision is as important as the choice of orchestration stack; see AI agent architecture patterns for related implementation choices.

Log decisions so an owner can reconstruct them

A production record should answer: what did the agent see, what sources did it retrieve, which tool did it call, what policy allowed or rejected the action, who approved it, and what changed?

Retain enough evidence to investigate a disputed result without retaining unnecessary sensitive content. The right retention period depends on your data policy and applicable obligations; it is not a universal number to copy from a checklist.

Change-triggered reviews beat calendar theater

The NIST AI Risk Management Framework provides a governance structure for identifying, measuring, and managing AI risk. It supports a repeatable risk-management approach; it does not prescribe one universal audit schedule for every agent.

Trigger a security and workflow review when you introduce:

• A new tool, integration, or data class.
• Write permissions or higher value limits.
• Browser, code-execution, or localhost capability.
• A new outbound communication path.
• Meaningful exception drift, rejected actions, manual overrides, or incident signals.
• A material change to the workflow owner, policy, model, or retrieval source.

Browser, code, and localhost agents need a separate boundary

Ordinary line-of-business agents using fixed internal APIs are not equivalent to agents that browse the open web, execute code, or communicate with local services.

Microsoft’s June 2026 AutoJack security research describes a concrete chain in which untrusted web content could reach privileged localhost services through missing authentication and unsafe command handling. It supports a specific point: localhost should not be treated as trusted merely because it is local, and browsing capability can create a route from hostile content to privileged execution.

For these agents, require:

This distinction matters when comparing AI agent frameworks or evaluating a platform that advertises browser or coding capabilities. Ask where authorization is enforced, how tools are isolated, what reaches the network, and how the vendor prevents one runtime from inheriting authority intended for another.

Commodity controls versus non-commodity risk

Failure modes and disqualifiers

Do not proceed to autonomous write access if you cannot name the accountable workflow owner, the approval path, the rollback method, and the evidence retained for each action. Those are disqualifying gaps, not documentation tasks to defer.

Build, buy, or use a partner

The right sourcing path depends on who can own the controls after launch.

A practical first-week decision checklist

1. Select one workflow with enough volume to measure and a named business owner.
2. Document the current path: inputs, systems, handoffs, exceptions, external effects, and manual review time.
3. Score the workflow and choose the lowest launch mode that can improve the target metric.
4. Create a service role and deny every tool, field, destination, and environment not needed for the pilot.
5. Define the approval queue, exception SLA, retained evidence, stop condition, and rollback test.
6. Run representative normal, ambiguous, and hostile-input cases before production data or write access.
7. Expand authority only after the pilot acceptance gate is met.

AI agent security is successful when the organization can explain why the agent has its authority, who owns its exceptions, how a bad action is contained, and what evidence justifies expanding it. That is a stronger operating model than a broad promise of autonomous work.

Apply this to your product

Arsum scopes AI product development and intelligent search and data systems. Bring one workflow, its intended users, permitted data sources and representative examples. The first implementation decision is the smallest useful scope that can be tested and handed over with a named owner.