AI agent security: permissions and safeguards

Securing an AI agent means limiting what it can read, change, and transmit, then checking sensitive actions before they run. Tools, accounts, and the execution environment must enforce these protections: instructions written for the model are not enough. Minimal permissions, separate secrets, sandboxing, human approval, and logging provide complementary layers of protection.

Start with the possible consequences

An agent drafting a sales response does not need the same access as an agent modifying a server. Begin by describing the task, the data it requires, and the consequences of a mistake: a disclosed document, an incorrect recipient, an overwritten file, a financial commitment, or an unavailable service.

Also distinguish between the sources the agent consults. A request from an authorized user, an incoming attachment, and a tool response do not carry the same authority. Content encountered during a task must remain data to examine, even when it looks like a technical instruction.

OWASP distinguishes excessive functionality, permissions, and autonomy in its explanation of excessive agency. This distinction helps frame practical questions: should this tool be available, should it have these permissions, and should the agent be allowed to use it without oversight?

Write down the scope before connecting accounts:

Authorized objective and expected result.
Accessible folders, applications, and categories of data.
Operations that are allowed, require approval, or are prohibited.
Responsible person and shutdown procedure.
Conditions for resuming work after an error.

The agent security assessment can help identify areas to examine. It does not replace checking the permissions actually granted in your environment.

Apply least privilege to every tool

Least privilege means granting only the permissions a task requires, for only as long as they are needed. Apply it to files, application accounts, network access, and the operations exposed by tools.

Separate reading, preparation, and execution. To process invoices, an agent can read a limited set of documents and produce drafts without being able to change bank details. A narrowly scoped business tool gives you more control over this task than general terminal access.

The service executing the operation must enforce restrictions. A parameter supplied by the model, such as a customer identifier, does not prove that the user is authorized to access that customer’s records.

Use case	Allowed reading	Allowed writing	Approval needed
Summarize documents	Selected folder	New summary in a dedicated workspace	Before external distribution
Prepare payment reminders	Relevant invoices and contacts	Draft messages	Before sending
Fix code	Copy of the relevant repository	Dedicated working branch	Before publishing or deploying
Analyze an incident	Required logs	Analysis report	Before modifying the service

This table provides a starting policy to adapt to your needs. Check indirect routes as well: a reading tool that can freely call an external address creates an outbound channel. A terminal can bypass the separation between specialized tools if it has access to their credentials.

Finally, remove old connections. A tool abandoned during a trial should not remain available by default.

Separate identities and protect secrets

Use a dedicated identity for the agent, or delegated access tied to the user who starts the task. Avoid giving it a personal account with administrator access. You should be able to suspend the automation without blocking everyone’s everyday work.

An API key, access token, session cookie, or private key is a secret. Do not put these in instructions, examples, or agent memory. The service responsible for executing a tool should retrieve the required credential without returning its value to the model.

The OWASP secrets management documentation covers access controls, rotation, and revocation. For your agent, assign each secret an owner, a purpose, a scope, and a replacement procedure.

A configuration file excluded from the repository is still readable by a process with the appropriate permissions. An environment variable is also accessible to the program that receives it. These distribution mechanisms do not provide separation from a terminal running under the same identity.

For a payment reminder workflow, the sending service can keep the email credential and accept only a structured operation after approval. The process responsible for reading invoices then has no reason to hold that credential.

If a secret appears in a conversation or log, remove accessible copies and revoke the credential at its source.

Choose a sandbox based on the access required

A sandbox limits the resources a program can access. Its effectiveness depends on its configuration: shared folders, privileges, networking, devices, and services reachable from inside the environment.

Prepare a disposable workspace containing only the files needed for the task. Mount source files as read-only when the task allows it, and use a separate folder for results. Keep personal directories, production credentials, and your usual browser sessions out of the environment.

Environment	Separation provided	What to check	Possible use
Dedicated system account	Separate permissions and files	Shared groups and resources	Restricted local tasks
Restricted container	Defined process environment and file access	Shared kernel, mounts, and privileges	Reproducible execution
Dedicated virtual machine	Separate guest operating system	Shared folders and networking	Less trusted code or stronger isolation needs

The Docker container security documentation explains risks associated with the daemon, mounts, and system capabilities. A privileged container, or one that can control the host’s container engine, substantially expands the access available.

Check the boundaries from inside the environment: try reading outside the permitted scope, writing to a prohibited folder, and accessing an unauthorized service. The test must demonstrate that access is actually denied.

The article Running an AI agent in a sandbox covers the practical setup. Here, the deciding factor remains the separation achieved, regardless of what the environment is called.

Control outbound network access and transmitted data

Preventing local writes does not protect data that an agent can send elsewhere. Review the available channels: web requests, messaging, uploads, browsing, synchronization, and log collection.

For each destination, define what data it may receive. Permission to contact the model provider requires deciding which excerpts will be included in requests. Permission to visit a website should not allow the agent to freely transmit internal documents to it.

Prefer a list of necessary destinations, enforced outside the process the agent controls. If a tool accepts an arbitrary address, also check how it handles redirects and internal network addresses. An address that appears public does not establish where the request will ultimately go.

Microsoft’s overview of AI agent security responsibilities highlights risks involving untrusted content and overly broad delegation. The operator must connect these risks to the connections they actually authorize.

Reduce data before transmission: remove unnecessary fields, select relevant documents, and limit attachments. Automatic redaction can help, but check its results against the formats you actually use.

In a hypothetical customer support scenario, the relevant message and case reference may be enough. Providing the customer’s entire history increases exposure without necessarily improving the resolution of the request.

Treat prompt injection as a risk to actions

A prompt injection attempts to make an agent follow instructions embedded in the content it processes. That content might be an email, a document, a web page, a tool description, or a search result.

The risk becomes concrete when those instructions trigger an action: sending a file, changing a recipient, or executing a command. Successfully completing an ordinary task therefore does not demonstrate that its boundaries can withstand hostile content.

The OWASP prompt injection glossary describes direct and indirect injections, along with the limits of protective measures. Explicit instructions and filters can reduce the risk, but cannot guarantee that the model will ignore every attempt.

Put several independent barriers in place. A document may request that something be sent, but the sending tool remains unavailable. A result may suggest another folder, but the service rejects paths outside the permitted scope. A page may claim there is an emergency, but it cannot grant new permissions.

Review displayed results as well. A link or remote resource generated from sensitive data can become a leak channel, depending on how the interface handles it.

The article AI agent security: risks and protections provides a broader overview. For daily operation, connect each risk to an observable control and a person who can intervene.

Set boundaries for MCP servers, extensions, and dependencies

Connecting an integration adds code, dependencies, and sometimes a remote service to the set of components you trust. Before installation, check its origin, maintainer, functions, and requested permissions.

Record what was approved: package source, selected revision, settings, exposed tools, and contacted destinations. An update should prompt a review of these elements. Changes to the code can alter the scope even when the connector’s name stays the same.

For a local server, examine the permissions of the process being launched. For a remote server, also examine authentication, transmitted data, and separation between users. In either case, hiding a tool in an interface does not replace access control.

The official MCP security best practices cover token validation, intended recipients, and delegation risks. A server must not blindly accept a token intended for another service. Access to a session or stored state must also remain tied to the authorized identity.

The guide Choosing an MCP server expands on these criteria, and the MCP server directory helps you find projects. A listing or high popularity does not amount to a security audit.

For an extension intended to read documents, ask why it also requests a terminal or full account access. If that scope cannot be reduced, choose another integration.

Design human approval around the exact action

A useful approval request shows what will happen: the operation, target, data involved, destination, and expected effect. A general request for permission to continue the task gives the reviewer too little information to decide.

For a message, display the final content, recipients, and attachments. For file changes, show the differences and affected paths. For a business operation, expose the parameters that determine its consequences.

Approval must be tied to that specific proposal. If the agent later changes the recipient, attachment, or operation, it needs fresh approval. The service executing the operation must verify that the action matches what was approved.

The OWASP AI agent security cheat sheet recommends separating decision and execution for irreversible operations. Implement this separation in the application, with denial by default when a required approval is missing or has expired.

Avoid approval fatigue as well. Reserve requests for transitions that change the risk: publishing, sending externally, deleting, modifying access, or making a financial commitment. Routine reading can remain automatic within an already defined scope.

Finally, provide a workable response to denial. The agent should be able to save a draft, explain why it is blocked, or request missing information. It should not look for another tool to carry out the denied operation.

Log operations without building a store of secrets

Logs should let you reconstruct actions relevant to an investigation: the initial request, identity, requested tool, authorization decision, any approval, result, and error. Distinguish a proposed action from an action that actually ran.

Use a common task identifier across components. Keep references to the affected objects and the parameters needed to understand what happened, while masking sensitive values. Text generated by the model is not, by itself, evidence that an action was executed.

The OWASP logging documentation explains what to record, what to exclude, and which protections to apply. In particular, avoid access tokens and passwords. Retaining complete documents and personal data also requires a reason.

Protect logs against modification by the agent. Define who may read them, how long they are retained, and how they are deleted. Also test system behavior when log collection fails: sensitive actions must follow an explicit policy.

Create alerts for understandable events: repeated denials, a new destination, permission changes, or activity continuing after a shutdown request. Every alert needs a recipient and a response procedure.

The guide Monitoring an AI agent in production explores how to organize logs and alerts. Collection provides protection only when someone can use the information.

Roll out gradually and test denied actions

Before starting, have a test environment, synthetic data, a responsible person, and a way to interrupt tasks. Tests must check boundaries as well as expected results.

Start with read-only access. Check which objects are accessed and what information is transmitted to external services.
Allow preparation. The agent produces drafts or changes in a separate workspace.
Test the restrictions. Introduce a document requesting a data leak, a prohibited path, and an unauthorized destination.
Add controlled execution. Verify that execution is denied without approval and blocked when parameters change after approval.
Expand after review. Grant additional access for an identified need, then repeat the relevant tests.

Also test cancellation during a task, account revocation, and isolation between users. An agent must not retrieve another session’s documents through shared memory with poorly defined boundaries.

For operations that might be repeated after an error, provide protection against duplicates. A timeout does not prove that a message failed to send or that a change failed to take effect.

Keep the expected results of these tests. Rerun the relevant scenarios after a change to the model, instructions, connectors, or permissions. A validated configuration is a state you must maintain, along with its dependencies and known limitations.

Common problems and incident preparation

The agent keeps asking for more permissions. Revisit the business need and the tool being used. A denial can reveal a missing permission, but it can also indicate an attempted action outside the authorized scope. Expand only the access identified as necessary.

The sandbox can see personal files. Examine mounts, inherited directories, and available credentials. Recreate a minimal environment, then verify from the agent’s process that access is unavailable.

Approval requests become hard to understand. Reduce the size of the operations presented and show their concrete consequences. A long sequence of actions should make its sensitive steps visible before anyone gives approval.

Logs contain confidential information. Fix collection at the source and address existing copies. Adding a filter to the viewing interface does not remove data already stored.

Prepare an incident procedure that is accessible independently of the agent. It must allow tasks to be suspended, connections to be cut, access to be revoked, and useful evidence to be preserved. Assign each operation to a responsible person.

After an incident, verify which actions actually ran and which data was accessible during the affected period. Restore from a known source, fix the failed control, and rerun the scenario before resuming operations. The agent’s written summary can help orient the investigation, but it must be checked against service logs.

Before putting the agent into service, verify the following:

Effective permissions match the written scope.
Secrets and unnecessary data are absent from the context.
File and network restrictions have been tested.
Approvals apply to the parameters actually executed.
Logs support an investigation without exposing credentials.
Shutdown, revocation, and recovery have a designated owner.

Frequently asked questions

Is an AI agent secure if it runs locally?

Running locally reduces some transfers to a hosting provider, but it does not determine the program’s permissions. A local agent can still read your documents, use active sessions, or transmit data through its tools. Check model hosting, connectors, and system access separately.

Can I put an API key in an agent’s instructions?

Avoid doing this: the instructions become another copy of the secret, which may spread through conversation histories and logs. Have the service that executes the tool use the credential instead. If a key has been exposed, revoke it with the provider.

Should I approve every action an AI agent takes?

Requiring approval for everything can make supervision difficult to sustain. Define routine operations that are allowed within a clear scope, then require approval for sensitive changes. General permission to complete a task should not count as consent to every consequence.

Does a sandbox prevent data leaks?

It can limit access to files and processes, but data can still leak through an allowed channel. An isolated environment that contains private data and can communicate freely still presents an exfiltration risk. Outbound filtering and data minimization remain necessary.

What should I do if an agent sends confidential information?

Suspend the agent and block the relevant access before resuming the task. Preserve useful logs, identify what information was transmitted, and revoke exposed credentials. Then have the appropriate people review the incident based on the type of data involved.

Securing an AI agent: permissions, secrets, sandboxing, human approval, and logging