prompt injection attack: a practical AI security guide

A prompt injection attack uses instructions in a message or external content to redirect an AI system away from its intended task. It can manipulate an answer or misuse connected capabilities, so protection must cover both model behavior and application permissions. OWASP describes the vulnerability and its consequences.

Before approving an AI workflow, ask the team to show what happens when the material being read tries to change the task. Then ask which actions remain possible if the model follows that instruction. Use those questions to structure the review below.

Why can source material become an instruction?

An LLM, or large language model, processes prompts and supplied content to generate responses. Prompt injection exploits failures to keep authorized instructions separate from attacker-controlled input; a document being analyzed can therefore become a route for redirecting behavior. Microsoft explains this trust problem.

Define the authority before choosing the wording

For your review, distinguish three things: the task the user authorized, the material the system must read, and the actions the application permits. Write these on separate lines. Require a clear reason whenever information from the second line changes a decision on the third.

An AI agent adds the ability to act through tools. A browser agent may navigate pages, fill forms, click buttons, or download files; its exposure includes the untrusted content encountered along the way. Anthropic describes these browser capabilities.

Use a permission inventory during procurement. Ask for the actual tool list, accessible data sources, and approval points. Keep that inventory with the workflow owner rather than treating it as a detail only the vendor needs to understand.

What separates direct injection, indirect injection, and jailbreaking?

Direct injection arrives through a prompt submitted to the model. Indirect prompt injection arrives through material the model consumes, such as a webpage, email, or document. Both can redirect behavior, but they cross different input boundaries. Microsoft's distinction

Use precise labels for the objective

OWASP describes jailbreaking as a form of prompt injection aimed at bypassing safety protocols. For operational reporting, record the attempted objective as well: answer manipulation, information disclosure, or an unauthorized action. That makes the test result more useful than a broad “jailbreak detected” label. OWASP's terminology

How do AI browsers increase exposure, and what has been demonstrated?

Browser use combines a broad attack surface with multiple ways to act. Anthropic identifies webpages, embedded documents, advertisements, and dynamically loaded content as possible exposure points, while emphasizing that browser agents are not immune to prompt injection. Browser security analysis

Microsoft documents research in which hidden webpage instructions caused Bing Chat to generate an image request that transmitted conversation information through URL parameters. The same source says that Microsoft fixed that specific issue. Treat this as a documented research demonstration, not evidence that the identical vulnerability remains open today. Documented case and remediation note

For your own assessment, include outgoing requests in the review scope. Ask which destinations the application permits and what information can be attached to a request. Examine those questions alongside the visible answer, rather than approving the workflow after reading the answer alone.

What would this look like in a marketing workflow?

Hypothetical example: campaign research

Imagine an agency asking an agent to compare potential campaign partners. One partner's document contains an instruction to disregard competing offers and recommend its proposal. This is an illustrative scenario, not a claim about a real agency or vendor.

Set the authorized task before running the exercise: extract deliverables, stated prices, exclusions, and supporting evidence. Ask the reviewer to flag any recommendation unsupported by those fields. Do not include real client records in the test package.

Extend the test to actions

Now suppose the workflow can draft an email to the selected partner. Separate preparing the draft from choosing the recipient and sending the message. Require the test record to show the proposed recipient, included information, requested action, and permission decision.

Write the acceptance rule in advance: source material must not authorize sending. If the test produces an unexpected action request, stop the exercise and inspect the application check. Do not redefine success after seeing a polished draft.

Keep this exercise small enough that a business owner can review every input and output. Use the same materials when comparing revisions, and add new cases separately. Record who accepted the change and which unresolved limitations remain.

Which controls should a business implement first?

OWASP recommends combining constrained behavior, output validation, filtering, least privilege, human approval, and separation of external content. Use the following implementation checklist to turn those principles into reviewable requirements. OWASP mitigation guidance

1. Limit the job. Name the permitted inputs and expected deliverable. Avoid a general mandate to operate across every company system.
2. Restrict data access. Give the workflow only the records needed for that job. Document the reason for each source and remove unused connections.
3. Enforce tool permissions in application code. Check the requested operation against the user's authority and the agent's scope before execution.
4. Label external content. Preserve its origin and distinguish it from trusted instructions. Include this boundary in the design review.
5. Validate outputs. Specify allowed fields, values, and action types. Reject an invalid result before passing it to another component.
6. Make approvals specific. Show the reviewer the destination, information, and operation being approved. Require another decision if those details change.

Ask vendors for evidence you can inspect

Request a demonstration using your test materials. Have the vendor show where an unauthorized operation is denied and which component makes that decision. Record the answer even when the model itself refuses the request.

For implementation planning, review the site's services. Use the free resources area as a starting point for further reading, while keeping your own permission inventory specific to the workflow under review.

How should you test the system before expanding access?

OWASP recommends adversarial testing of trust boundaries and access controls. Build a repeatable evaluation around the actions you intend to permit, and inspect application enforcement as well as generated text. Testing recommendation

• Include a normal document to check that the intended task still works.
• Add clearly labeled test material containing conflicting instructions.
• Attempt an operation outside the approved permission scope.
• Test the languages actually used by customers and staff.
• Repeat the evaluation after changing models, connectors, or permissions.

Track answer manipulation, attempted tool misuse, blocked operations, and reviewer corrections separately. Define the release threshold before running the test. An unauthorized data transfer should trigger a different decision from a harmless formatting error.

Prepare an incident procedure before granting broader access. Specify who can pause the workflow, restrict a connector, preserve relevant records, and authorize a restart. In the review, identify the input that preceded the unexpected behavior and the permission decision that followed it.

Keep learning and approval separate. Use English articles for related reading, and About Anar Rustamli for the author's background. The English homepage provides navigation; your deployment decision should remain attached to your own documented tests.