AI agent security: check permission before tools act

A customer email arrives with an attachment. An AI assistant reads it, drafts a reply, and proposes a CRM update. The attachment also contains a request to send an internal customer list to a new address.

The first useful security question is simple: even if the model follows that request, can the surrounding application actually carry it out?

How can a small business reduce prompt-injection risk in an AI workflow? Keep incoming content separate from the authority to act. Give the model only the records and tools its task needs, validate each proposed operation outside the model, and require specific approval for consequential changes. Test that a manipulated request is blocked at the tool boundary, then verify the real system state.

Our earlier guide to AI agent onboarding covers ownership and access. This article goes further into one failure path: outside content influencing a tool call. The worked design below uses a fictional inquiry assistant; it is not a claim that Opslumo has discovered a breach or tested a customer's system.

A timely reminder: actions carry business risk

On September 21, 2026, the UK's National Cyber Security Centre published guidance on agentic cyber defence. It argues that defensive automation must account for organizational constraints and responsibility, and considers the power, scope, criticality, rollout confidence, and recoverability of an action. Its context is cyber defence, not customer service.

For a small business, we can apply that decision lens to an everyday workflow. Suggesting a reply, sending it, changing a customer record, and removing someone's access have different consequences. A useful assistant should not receive all four capabilities merely because the platform bundles them together.

Why a stronger prompt is only one layer

Indirect prompt injection occurs when instructions embedded in material the AI processes—such as a document or retrieved webpage—redirect its behavior away from the authorized task. The attacker does not need to be the person operating the assistant.

The NCSC's December 2025 analysis explains why a prompt is not a reliable security boundary between instructions and untrusted data. It recommends constraining possible actions through deterministic safeguards as well as reducing the likelihood of manipulation. An instruction telling the model to ignore suspicious text may help, but it does not remove the need for those controls.

Keep the source attached to extracted facts. If a summary says “the manager approved this export,” the workflow should still know that the statement came from a customer attachment. Summarizing text must not upgrade the sender's authority. The same caution applies when a retrieved document calls itself an internal policy.

Work through one inquiry assistant

Consider a fictional repair company whose assistant reads new inquiries, drafts a response, and suggests a follow-up task. A sensible first version can work with a single inquiry and a small, approved service-information set. It does not need the entire customer database.

OWASP's 2025 Excessive Agency guidance identifies unnecessary functionality, permissions, and autonomy as sources of risk. It recommends narrow tools, minimum downstream permissions, and authorization enforced beyond the model. The edition is stated here deliberately; the design principle matters more than its position in a ranked list.

For this example, translate the role into three operations:

• Read the assigned inquiry: the application supplies a verified record identifier. Text inside the inquiry cannot choose a different customer's record.
• Save a draft: the assistant can write to a review queue. Draft creation does not send a message or mark a customer as qualified.
• Apply a reviewed action: a separate execution component uses its own narrowly scoped permissions after the required checks pass.

The model cannot bypass the review queue through a second connector that still has send access. Review every available path, including old integrations left enabled during testing.

Read-only access also needs limits. An assistant that reads sensitive material and can open arbitrary URLs may still transmit information through an outbound request. Restrict what it can read, which network destinations it can reach, and what data those requests can contain. “It cannot edit the database” answers only part of the security question.

Make approval describe the actual operation

A button saying “Approve the assistant's recommendation” gives the reviewer too little information. Show the exact recipient, message, attachments, affected record, and proposed field changes, alongside the source inquiry. Render untrusted text as content, so an attachment cannot visually impersonate an approval control.

OWASP's Transaction Authorization Cheat Sheet calls for server-side enforcement, verification of significant transaction data, and checks immediately before execution. It also addresses limited validity, unique authorization, and changes to transaction data. We apply those principles to a business workflow here, rather than treating an email draft as a financial transaction.

The application should reject an attempt to change the recipient or attachments after approval. A material edit requires a fresh decision. The approval record must be created by the trusted application, not accepted from a sentence in the model's output.

For retries, record a unique action identifier and reconcile the delivery result before resending. A network timeout does not prove that the first email was never sent. This is both a security control against repeated actions and an ordinary reliability requirement.

Put the check where the tool executes

Ask the implementer to show which component can reject the operation even when the model insists it is valid. The check belongs in trusted application code or the downstream service, with policy and credentials the model cannot rewrite.

OWASP's Agent Control Standard page, published September 1, 2026, describes middleware hooks for runtime policy enforcement across agent frameworks. It is relevant architecture guidance, not evidence that a particular product or workflow is secure.

For the inquiry assistant, the execution check should confirm the current identity, permitted operation, record scope, exact approved content, expiry, and whether the action has already been used. If the approval store or policy service is unavailable, hold the action and notify its owner. Do not let the assistant invent an alternative route around the failed check.

Some small teams will not have software capable of enforcing that separation. A useful intermediate design is to keep the AI in a draft queue and let staff send from the existing helpdesk. Describe that limitation plainly rather than presenting a policy document as a technical barrier.

Six tests worth running before enabling writes

Use a staging environment, synthetic records, and destinations you control. These are suggested acceptance checks for this example, not a complete penetration test. Verify tool logs and destination-system state; a model saying “I refused” is not enough.

Include ordinary inquiries as well. The assistant should still produce useful drafts without unnecessary access. Repeat the relevant checks when a connector, permission, approval rule, or workflow version changes. Passing this set gives evidence about those cases, not proof that all prompt injections will fail.

Plan for the action that already happened

If a suspicious request produces an unexpected tool call, pause further execution and preserve the relevant evidence. Check queued work, revoke affected access where appropriate, and establish what the destination system actually received. Stopping the scheduler may leave an already issued request in flight.

Keep logs useful and bounded: record the action identifier, input reference, policy decision, content version, approver, and outcome. Restrict access and define retention. Avoid collecting entire mailboxes or secrets merely to make the log look comprehensive.

Recovery depends on the consequence. A CRM field may be restorable from a prior value. An email sent to the wrong recipient cannot reliably be taken back. A suspected disclosure needs an incident assessment and the organization's established response process; replaying the workflow is not recovery.

Our AI agent control-center guide explains how to keep ownership and shutdown decisions visible. This deeper check supplies the missing proof: can the workflow reject an unauthorized operation, and can someone reconstruct what happened?

Before connecting another tool, ask for one demonstration: present a manipulated inquiry, show the denied action in the execution log, and verify that the customer system stayed unchanged. That is a more useful starting point for an AI workflow project than a promise that the prompt is secure.