Agentic AI Security: Why Prompts Aren’t Access Controls

An agent can act with your credentials

An AI assistant that drafts text presents a different business risk from an agent that reads customer records, sends email, or changes cloud resources. Once an agent can take action, the security question becomes practical: what can it do, for whom, and under which conditions?

Instructions such as “never disclose confidential information” are useful guidance. They do not replace the permission checks that decide whether a specific action is allowed. The model should propose an action; a separate application control should decide whether it may execute.

That distinction matters when a workflow consumes material your business does not control, including incoming emails, uploaded documents, and retrieved web content.

When external content becomes an instruction

Indirect prompt injection occurs when an attacker places instructions in content an AI system later processes. The agent may mistake that content for directions it should follow. OWASP identifies manipulated model output, excessive permissions, and excessive autonomy as ingredients of excessive agency.

Consider this illustrative scenario, not a client incident:

1. The legitimate task: a support agent reads an incoming message and prepares a customer response.
2. The planted instruction: the message tells the agent to retrieve account details and send them to an external address, presenting this as a required verification step.
3. The attempted action: the agent requests a tool call using the application’s legitimate credentials.
4. The enforcement point: the backend checks the requesting user, permitted records, recipient, and approved purpose before allowing the call.

If those checks reject the destination or data access, the request is blocked even if the model tries to comply. This is a confused deputy problem: a system with legitimate authority is persuaded to use it on someone else’s behalf.

Three boundaries to design before launch

1. Tool access: make permission specific

Define the actions each workflow needs. Reading a single customer’s ticket should not require exporting the customer database. Separate read access from write or delete access, and bind permission checks to the current user and resource.

Enforce those checks where tools execute. An agent-generated field saying “approved” is not evidence of approval.

2. Consequential actions: require meaningful approval

For a sensitive action, show a reviewer the exact destination, affected records, and proposed change. Tie approval to those details so a later change requires another review. Decide which actions are prohibited entirely, regardless of what the model or reviewer requests.

3. Retrieved content and memory: preserve trust boundaries

Keep external content separate from privileged instructions. Limit who can write persistent memory, isolate customer data, and retain enough provenance to investigate a suspicious result. A signed document may prove its origin and integrity; it does not prove that its instructions are safe.

These controls follow the defense-in-depth approach described in the OWASP AI Agent Security Cheat Sheet. The right implementation depends on the workflow. Separate microservices are one possible design, not a prerequisite for enforcing a boundary.

Test the whole workflow, not just the chatbot

A useful security evaluation asks whether manipulated content can produce a consequential action. A model refusing one obvious malicious prompt does not demonstrate that the surrounding application is secure.

Before approving an agent for production, ask your team to demonstrate:

• Cross-customer isolation: can a request cause the agent to retrieve another customer’s records?
• Destination restrictions: can a tool send sensitive information to an unapproved address or endpoint?
• Approval integrity: can the agent change an action after a person approves it?
• Memory isolation: can untrusted content influence a later task or another user’s session?
• Failure behavior: what happens when the authorization service is unavailable or a tool returns unexpected data?
• Investigation readiness: can you trace a tool action to the request, permission decision, and outcome without unnecessarily logging sensitive content?

Run authorized tests in a controlled environment with defined scope and safe test data. Document both blocked attempts and successful unauthorized actions, then retest the fixes.

Deterministic controls still need good policies

An authorization check can consistently enforce the wrong rule. A broad “send email” permission may still allow an unwanted message, and an approved workflow may still produce an inaccurate answer. Architecture reduces the consequences of model mistakes; it does not make the model infallible.

Keep conventional application security in scope too: authentication, secret management, input validation, dependency security, and tenant isolation. AI-specific testing adds scenarios to that work. It does not replace it.

Start with the actions your agent can take

List the tools, data sources, and external destinations your agent can reach. For each, identify who authorizes access, where the check runs, and how you will prove that it works. That inventory gives engineering and security teams a concrete starting point.

At Iron Fist Labs, our team includes an OffSec AI Red Teamer (OSAI) certified professional. If you are building an AI-enabled workflow, we can discuss a security testing scope around its tools, data access, and business impact.

Explore AI Security Testing and discuss your workflow, or explore our penetration testing services for broader application and infrastructure testing.