AI agent security: protect business data before connecting tools
Prompt injection becomes a business risk when an assistant can access records or take actions. Start with permissions, isolation and reviewable changes.
An assistant that drafts text has a different risk profile from an assistant that can read customer records, change invoices or send messages. Connecting tools changes the consequences of a wrong instruction. AI security therefore belongs in the project brief before the assistant receives access.
The official OWASP LLM Top 10 repository identifies its 2026 release as current. It includes prompt injection, sensitive information disclosure, excessive agency, unbounded consumption and improper output handling. These categories help frame the discussion; they do not replace a review of the particular application and its permissions.
This guide offers Moonera's planning recommendations for a business evaluating an AI assistant or automated workflow.
Understand where instructions can enter
Prompt injection occurs when untrusted content influences a model's behaviour in an unintended way. An assistant can encounter instructions inside a document, retrieved webpage or tool response as well as in a direct user message.
Consider a support assistant reading an uploaded document. The file might contain ordinary product information and text asking the assistant to reveal unrelated records or send information elsewhere. The application needs to preserve its access rules regardless of what the file says.
A prompt telling the model to behave safely is useful context. It should sit alongside enforceable controls over the tools, records and destinations the application allows.
Give each tool a narrow job
Describe permitted actions in business terms. “Read the signed-in customer's open tickets” is a clearer permission than “access the support database.” “Prepare a reply for review” has a different impact from “send any reply to any address.”
- Enforce the user's access to each requested record on the server.
- Expose specific tool actions with validated arguments.
- Separate read access from write or send permissions.
- Restrict external destinations where the workflow allows communication.
- Keep secrets out of prompts and user-visible tool output.
An assistant should not inherit broad administrative credentials merely because that makes an integration easier to demonstrate. Permissions need to remain meaningful when the model makes an unexpected choice.
Separate execution from valuable credentials
For assistants that execute generated code, the environment matters. Anthropic's Managed Agents architecture discussion describes keeping credentials beyond the execution sandbox's reach. That separation illustrates a wider principle: limit what a compromised execution environment can obtain.
In a project review, ask where credentials are held, which network destinations are reachable and what files the execution environment can read. The appropriate boundaries depend on the task. A document summariser and an internal engineering agent should not receive identical access simply because both use a language model.
Make important changes reviewable
For customer-facing communication or business-record changes, show a person the concrete proposed action when review is required. The review should identify the target, the intended change and any material uncertainty. Approval of a vague goal gives less useful control than approval of the prepared action.
Review frequency also needs care. If every harmless read requires a click, people may stop paying attention. Design a policy that gives routine operations a clear boundary and reserves meaningful review for actions with consequences.
Validate output before using it elsewhere
Model output is application input when it reaches another system. A proposed database field needs type and permission checks. A generated link needs an allowed URL scheme. Text shown in an admin interface needs safe rendering.
Likewise, data retrieval needs its own access checks. A search index or vector store should return records the current user is allowed to see. Moving confidential material into a retrieval system does not remove the original ownership rules.
Test failure and control consumption
Build an evaluation set with normal requests, misleading retrieved content, missing information and unavailable tools. Observe whether the system stays within permissions, records its actions and stops when it reaches a defined limit.
Set maximum input sizes, execution time, tool calls and spending thresholds appropriate to the use case. Plan how to pause the integration and revoke credentials if behaviour becomes unexpected. Logs should support investigation while avoiding unnecessary retention of private content.
These controls reduce particular risks; they do not make an AI application attack-proof. For a first implementation, the workflow versus agent decision guide can help identify how much autonomy the task needs. Discuss AI automation with Moonera alongside the application's security scope.
Sources and further reading
Research checked on 30 October 2026. Recommendations here are planning guidance, not a completed security assessment of your application.
