Prompt Injection Defense for Business AI: Practical Checks

Prompt injection defense for business AI means making sure that text an agent reads, such as an email, a shared document or a web page, cannot change what the agent is allowed to do. The working method has three parts: treat retrieved content as data rather than instructions, give the agent only the tools its role needs, and place a human approval in front of any action that sends, spends, deletes or shares something. These controls are design decisions you can verify before launch, so they do not depend on hoping a filter catches every hostile sentence.

Key takeaways

• Treat every email, document and web page an agent reads as untrusted material, never as instructions.
• Give each agent a named role with the smallest set of tools and permissions that role uses.
• Put an approval step in front of any action that sends outside the company, shares files, changes records or moves money.
• Log which sources were read, which actions were proposed and which were blocked, so suspicious steering is visible.
• Test with hostile sample messages before launch and repeat the same tests after every change.

How an injected instruction reaches your agent

An agent that reads your inbox, a supplier folder or a public web page is reading text that someone else may have written. Indirect prompt injection happens when that text contains instructions aimed at the agent rather than at a person. The OWASP guidance on large language model applications lists prompt injection among the main risks, and the reason is structural: the model receives the company's instructions and the content it reads as one stream of text.

Illustrative scenario: a small distributor runs an agent that summarizes incoming supplier emails and drafts replies. One message contains, in a footer almost invisible to a human reader, a sentence asking the assistant to forward the current product list to an outside address and to skip the usual confirmation. If the agent holds a send permission and no approval step exists, the instruction may be followed. The weakness is not that the model was careless. The weakness is that the agent could act on text it read, with no boundary between reading and doing.

Direct injection, where a user types a malicious request into the agent, matters as well. In business settings, though, indirect injection is the case that surprises owners most, because the attacker never speaks to the agent at all.

Treat retrieved content as data, not instructions

Write the agent's operating rules so that content it retrieves is described as material to analyze, never as a source of commands. The rules should state that emails, documents and pages may contain requests the agent must not follow unless they match one of the approved tasks for its role. This wording helps, but a model can still be persuaded by well-written text, so treat it as one layer among several.

Separation also helps in practice. Pass the agent only the fields a task needs rather than whole mailboxes or folders, which is the same principle behind data minimization. Where your tooling allows it, keep source content in clearly labeled fields, and flag hidden text such as off-screen content, comments, metadata and unusual invisible characters before the model reads them. Finally, be careful when one agent's output becomes another agent's input. Each hop can carry an instruction forward, so the second agent needs its own boundaries and should not trust the first one's summary blindly.

A pre-launch checklist for prompt injection defense

• List every source the agent reads, including inboxes, shared drives, form submissions, uploaded files and any web search it performs.
• For each source, write down who can create content in it. Anyone outside the company is untrusted by default.
• Write a short role description with allowed tasks and an explicit list of requests the agent must refuse.
• Remove every tool and permission the role does not use. Read-only access is the default, and write access is added only with a reason.
• Confirm that outbound messages go either to an allowlist of approved domains or into a review queue.
• Strip or flag hidden text, comments and metadata before the model reads the content.
• Prepare a set of hostile test messages: one asking to forward data, one asking to change a record, one asking the agent to ignore its earlier rules, and one pointing to an unfamiliar link.
• For each test, write the expected result, run it, and record the action taken and whether a person was asked.
• Repeat the full set after any change to prompts, tools, model version, connected accounts or data sources.
• Name one owner who can pause the agent and who reviews the test results each week during the first month.

Which actions must stop and wait for a person

The most useful control is a clear decision guide that every team member can read. Sort actions by their consequence, not by how difficult they are for the agent to perform.

• Read and summarize content inside the approved scope: allowed automatically.
• Draft a reply or a document: allowed, saved as a draft that a person reviews before it leaves.
• Send a message to someone outside the company: requires approval each time, at least during the first phase.
• Share a file or change access permissions: requires approval, without exception.
• Create, change or delete a record in a system of record: requires approval, with the proposed change shown before it is applied.
• Move money, issue refunds or change bank details: blocked for the agent and handled only by staff.
• Open a link found in unknown content: blocked unless the destination is on an allowlist.
• Anything the agent cannot classify with confidence: stop and ask.

The OWASP authorization guidance is a useful reference for this stage because it treats access as a decision checked at the moment of each action, not something assumed from an earlier step. If a suspicious instruction arrives in the middle of a long task, the agent should still face the same boundary when it tries to send. For a fuller model of how trust can grow over time, see permission tiers for superintelligent agents, and for the approval design itself, see where an AI agent should stop and ask.

What to log and how to respond when steering happens

Logs are what turn a silent failure into a visible one. Record which source items were read, which tool calls the agent proposed, which were blocked, which approvals were requested and who answered them. Set alerts for proposed calls to domains outside the allowlist, for outputs that refer to instructions found inside content, and for repeated attempts at a blocked action. Keep those records under a retention rule that balances audit needs against privacy.

When steering is suspected, the response should follow a written path. Pause outbound actions first, preserve the transcript and the source message, identify exactly which actions were proposed and which completed, and notify the people affected if any data left the company. Then repeat the hostile test set before reopening the agent. A pause mechanism is only useful if someone has tested it on a normal day, so practice it before an incident. The article on kill switches for superintelligent agents covers how to pause actions without losing the work in progress.

How Be Human handles this in managed operations

Be Human's managed approach begins before an agent touches real content. The first engagement defines one useful role, the sources it may read, the tools it may call and the approval boundaries for each action type, and it sets an observable success criterion alongside them. Managed operations then cover monitoring of the logs and alerts described above, recurring hostile tests after each change, permission reviews that remove access the role no longer needs, and incident response with a named owner. Controlled improvements are released only after the test set passes again, so the agent's reach stays visible and bounded over time.

Start with one agent and one protected workflow

Choose a single workflow where the agent reads outside content but its possible actions are narrow, such as sorting incoming supplier questions into drafts for a person to send. Write the approval boundary and the hostile test set before connecting any sending account, and review the results with the person who owns that workflow every week until the boundaries hold. Take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can prompt injection be fully prevented? No single control prevents it completely, because a model reads instructions and content as one stream of text. The practical goal is to limit what a successful injection can do, through narrow permissions, approval steps, allowlists and monitoring. Those limits turn a possible manipulation into a blocked or clearly visible event.

Do I need a special AI security product before I start? Not necessarily. Many protections are configuration and process decisions, such as which accounts the agent can use, which actions need approval and what gets logged. Specialized tooling can help later, but the first defenses can be reviewed with your existing operations and security people.

Should we test with realistic attack messages? Yes, but run them in a test environment or with accounts that cannot cause harm, and never send hostile samples to customers. Write each test with an expected result, such as the action being blocked or routed for approval. Repeat the full set after every change to the prompt, tools or connected accounts.

Who is responsible if an injected instruction leads to a bad action? The company that deploys the agent remains accountable for its permissions and approval design, even when the trigger came from an outside party. That is why the boundaries, logs and test records should be owned by a named person inside the business rather than left to the tool vendor alone.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.