AI agent security: permissions, boundaries and audit

The security of AI agents rests on three pillars: the reach of their permissions, their autonomy on critical decisions and complete traceability of what they do. These systems do not behave like conventional users; they run tasks at machine speed and they are vulnerable to manipulation of the content they process. Under that paradigm, least privilege stops being a recommendation and becomes a technical requirement. Note: this content is strictly informational and does not replace legal advice or a formal security audit. Validate your implementations with your CISO, your legal advisers and the guidance of your national cybersecurity authority or ENISA at EU level.

In short

• An agent inherits the permissions you give it: give it the administrator account and you have created a manipulable administrator.
• Indirect prompt injection is the vector specific to agents: the attack arrives inside a document, an email or a web page the agent reads.
• Autonomy is raised in bands and by type of action, not for the agent as a whole.
• Without an action log there is no audit and no honest way to measure the RAO (Operational Autonomy Ratio).
• Useful reference frameworks: OWASP Top 10 for LLM Applications, MITRE ATLAS, NIST AI RMF and ISO/IEC 42001.

Why is an AI agent not secured like a normal application?

Because the line between data and instructions disappears. A classic application runs the code you wrote for it. An agent decides what to do from text, and that text can come from outside: an email from an unknown sender, a PDF from a supplier, a web page, a support ticket.

That produces three practical differences:

1. The input is hostile by default. All external content the agent reads is potentially an instruction.
2. The agent acts. It sends, writes, deletes, pays, publishes. The damage does not stop at a wrong answer.
3. Scale amplifies. A human error affects one case file; a badly configured agent repeats it a thousand times in an hour.

What are the real attack vectors?

Which ten controls should always be applied?

1. Real least privilege. A technical user per agent, with read-only permissions except where writing is essential. Never shared administrator accounts.
2. Permissions inherited from the end user. If an employee cannot see a folder, neither can the agent acting on their behalf.
3. A closed tool catalogue. The agent can only invoke declared functions, with a validated parameter schema.
4. Execution isolation. A separate environment, with no network access except to permitted destinations, and no access to the host filesystem.
5. External content marked as untrusted. What the agent reads is data, never an instruction. That applies to the results of its own tools too.
6. Human approval by type of action, not per agent: reading, yes; writing to the ERP, depending on the amount; sending externally, always with review at the start.
7. Explicit, numeric limits of authority. Maximum amount, number of recipients, record types it can modify, operating hours.
8. Secrets managed outside the context. A credential vault, short-lived tokens, scheduled rotation, no keys in prompts or repositories.
9. A complete, immutable log. Every action with the agent, version, tool, input, output, the user it acted on behalf of and the timestamp.
10. A stop switch. A button that halts the agent and revokes its credentials in seconds, tested regularly.

How do you raise autonomy without opening a hole?

With a four-band ladder, applied by type of action and not per agent:

This ladder is why at NEXTAI the RAO (Operational Autonomy Ratio) is measured per process: the same Superagent can be in band 3 for classifying documents and in band 1 for sending communications to clients.

What does a real failure look like and how do you prevent it?

An illustrative example built on the types of incident detected in projects.

An industrial company of 180 employees deploys an agent that reads the orders mailbox and creates the order in the ERP. An incoming email includes, in the footer of the attached PDF and in white text on a white background, an instruction aimed at the agent to change the supplier's bank account.

With no controls, the agent has permission to modify the supplier record and executes the change. With the controls in the previous section it does not happen: the PDF content is marked as untrusted, the available tool only allows creating orders and not modifying master data, and any change to bank details sits in band 1 with mandatory human approval.

The lesson is that the effective control is not a better text filter, but a shorter tool list. The defence is not detecting the attack, but making sure the dangerous action does not exist in the agent's catalogue.

Which reference frameworks are worth using?

• OWASP Top 10 for LLM Applications, for the catalogue of vulnerabilities specific to applications built on language models.
• MITRE ATLAS, for tactics and techniques used to attack AI systems.
• NIST AI Risk Management Framework, for structuring risk management.
• ISO/IEC 42001, as an AI management system, alongside ISO/IEC 27001 for information security.
• In public sector work and among its suppliers, the applicable national security framework shapes the design.

None of them replaces a security professional reviewing your specific architecture.

How NEXTAI does it

At NEXTAI every Superagent is deployed with its own user, a closed tool catalogue, a budget per run, numeric limits of authority and an immutable log. Security is part of layer 5 of the Enterprise Brain and phase 5 of the NEXT-5 Roadmap, and each agent enters the registry described in AI governance. Autonomy rises band by band on evidence, not on trust.

Frequently asked questions

Can prompt injection be prevented entirely? Not with text filters. It is mitigated with architecture: separate content from instructions, limit the tool catalogue, require human approval on sensitive actions and give the agent no permissions it does not need. You assume the attempt will happen and design so that it has no consequences.

What permissions should an agent have on day one? Read only, and over the minimum set of sources the process needs. Write permissions are granted action by action, after two weeks in the observation band with no material errors.

Does each agent need a separate user? Yes. A technical user per agent lets you audit, revoke and limit independently. Sharing credentials between agents, or with people, destroys traceability and makes the basic question of who did what impossible to answer.

How do you audit an agent? With a log capturing the input, the tool invoked, the parameters, the output, the user it acted on behalf of and the timestamp, plus periodic sampling of runs reviewed by a person. Without that log you cannot evidence anything to any auditor.

Is it safe to give an agent internet access? Only under a strict allow-list policy and with mechanisms that block exfiltration to unauthorised destinations. Unrestricted browsing is a critical weakness, turning any website into a potential data leak route. If you need to review the map of permissions and limits of your live systems, start by analysing your infrastructure with our free Digital Audit.