Organizations protect themselves against prompt injection by making it a managed operational risk rather than assigning it entirely to a chatbot's prompt. I would give each AI workflow a named owner, document the authority it carries, and require evidence that important limits are enforced before expanding access.
This article focuses on governance: deciding who is responsible, what evidence a release needs, how vendors are assessed, and what happens after an incident. Engineering controls are essential, but they remain inconsistent if nobody owns the decisions about data, permissions, deployment, and ongoing changes.
Inventory workflows instead of counting chatbots
A list of approved AI products does not reveal what those products can do inside your organization. The same assistant may summarize public articles for one team and access confidential customer records for another. Those are different risk decisions even if both teams use the same subscription or underlying model.
I would inventory workflows with their business purpose, users, data sources, connected tools, external destinations, and possible side effects. Include less obvious entry points such as support tickets, shared documents, browser content, repository files, and integration responses. Record whether the assistant can only suggest an action or execute it directly.
Start with the systems that combine sensitive reading with consequential action. An incomplete but actionable inventory of the highest-impact workflows is better than waiting months for a perfect catalogue while new integrations quietly accumulate permissions. Update the inventory when a connector or use case changes.
Assign owners who can actually make decisions
Each workflow needs a business owner who can explain the intended outcome and accept the remaining risk. It also needs technical ownership for permissions and enforcement, security ownership for assessment, and an operational contact for incidents. These roles may overlap in a small company, but the responsibilities should not disappear.
I would document who can approve a new data source, enable a write-capable connector, change an approval requirement, and disconnect the service during an incident. If every decision requires finding an unknown administrator, the process will either stall or be bypassed. Name a deputy so absence does not become an excuse for unsafe exceptions.
Ownership should follow the actual authority involved. A marketing team cannot authorize access to payroll simply because its assistant could benefit from more context. The relevant data and system owners must participate when their resources enter the workflow.
| Decision | Accountable role | Evidence to request |
|---|---|---|
| Connect a new data source | Data and workflow owners | Purpose and access matrix |
| Enable an external action | System owner | Permission and approval test |
| Release the workflow | Business owner with security review | Test record and residual risks |
| Respond to an incident | Operational lead | Revocation and action audit trail |
Classify consequences before choosing safeguards
Do not classify an AI deployment as low risk merely because its interface looks like a conversation. Consider the worst plausible outcome of its available capabilities: revealing confidential information, changing a record, sending a message, approving a refund, or running code. Then consider who could influence the material it reads.
I would group workflows by consequence and reversibility rather than inventing a universal numerical safety score. A public FAQ assistant with no private retrieval differs from a finance assistant that can initiate transactions. Both need controls, but their release evidence and escalation paths should differ.
For high-impact tasks, the right decision may be to remove autonomous execution or avoid the proposed AI workflow entirely. Documenting that limit is a valid outcome. A governance process should support a narrower useful deployment instead of treating every requested capability as an inevitable launch requirement.
Set a minimum control baseline
A baseline should describe observable behavior. Examples include checking the caller's access before retrieving records, keeping secrets outside model context, separating external content from trusted configuration, restricting tool permissions, and requiring specific review for consequential actions. The baseline should identify who verifies each requirement and how.
I would avoid accepting “the model is instructed to be safe” as sufficient evidence for an authorization control. A reviewer should be able to point to the service, policy, or configuration that rejects an unauthorized operation even when the model requests it. Where enforcement depends on a vendor, request a clear description of the responsibility boundary.
Allow documented exceptions with an owner, expiry date, and compensating measures. An exception should not silently become the permanent architecture. Reassess it when the workflow grows, because a tolerable read-only experiment may become a very different service after email or administrative tools are added.
The NCSC risk guidance supports treating residual prompt injection risk as a design and operational responsibility rather than expecting a complete filtering cure.
Ask vendors questions tied to your workflow
A vendor's broad security statement cannot answer every question about your deployment. Ask which identities its tools use, whether access follows the individual user, what information enters model context, how connected credentials are handled, and which actions can be restricted. Ask what is logged and how quickly access can be revoked.
For prompt injection specifically, I would request an explanation of what happens when retrieved content asks for an unauthorized action. Does the product merely ask the model to refuse, or does another component deny the operation? Can your administrators enforce limits, or can an end user switch them off? What changes after a connector update?
Use a controlled evaluation with synthetic data to verify critical claims. Certifications and questionnaires can support procurement, but they do not replace a task-specific assessment. Record unresolved limits so teams do not assume a purchased product has solved every problem by default.
Create a release gate with practical evidence
A useful release gate asks whether the workflow meets its stated purpose within its allowed authority. Evidence can include the access matrix, tool inventory, example approval screens, adversarial test outcomes, logging coverage, and a demonstrated shutdown path. Keep the evidence understandable to the people approving the service.
I would test at least one hostile item in every important input channel. A malicious sentence in a public page does not exercise the same route as an instruction in a customer attachment or a tool result. Use harmless fixtures that request a prohibited operation and verify the operation is rejected outside the model.
Also test legitimate work. A system that blocks almost everything may encourage employees to export data into personal tools. Release decisions should consider both security failures and usability failures, then narrow the workflow or improve controls rather than declaring success from a single refusal screenshot.
Train people around actual decisions
Training should show employees how prompt injection appears in their own tasks. A support agent needs to recognize that a ticket cannot authorize access to another customer's record. A recruiter needs to understand that a résumé cannot instruct an assistant to change the evaluation process. Generic warnings are less memorable than concrete boundaries.
I would teach three habits: treat outside content as material to analyze, inspect unexpected action requests, and report suspicious behavior through a known channel. Explain that a confident assistant can still propose the wrong operation. Approval fatigue should be treated as a workflow problem, not simply a failure of staff attention.
Give teams a supported way to get useful work done with limited permissions. If the only approved process is unusably slow, shadow integrations become more attractive. Training works best when the safer path is also clear, available, and aligned with the job.
Prepare an incident process before deployment
An incident runbook should identify how to pause the workflow, revoke credentials, preserve relevant evidence, and find affected actions. It should distinguish a blocked attempt from an actual disclosure or unauthorized change. Both can teach useful lessons, but they require different responses and communications.
I would run a short exercise using a fictional malicious document and a dummy account. Ask the team to locate the source, identify the tool identity, determine which operations occurred, and stop further access. If those answers take hours to assemble, improve the logging and ownership before granting more authority.
Preserve evidence carefully. Logs may contain private source material, so restrict access and apply a retention policy. When a real incident affects personal or contractual data, involve the appropriate internal specialists. The technical team should establish facts without improvising legal conclusions or public claims.
Reassess when the system changes
AI workflows change through more than model upgrades. A new retrieval source, expanded connector scope, revised system instruction, changed tool schema, or new memory feature can alter the attack surface. Make those changes visible to the workflow owner rather than treating them as harmless maintenance.
I would track a few meaningful measures: confirmed unauthorized attempts blocked or executed, time to revoke access, high-impact actions requiring review, and legitimate tasks disrupted by controls. Avoid a dashboard that celebrates the number of suspicious phrases detected without showing whether important boundaries held.
A sustainable program gives people a repeatable decision process: identify authority, constrain it, verify the constraints, and revisit them as the service evolves. The organization then depends less on individual vigilance or one vendor promise, while still allowing carefully bounded AI assistance to deliver value.
Common questions
Is this only a security team problem?
No. Business, data, engineering, and operational owners make decisions that determine the system’s authority. Security review helps those owners assess the resulting risk.
Should all AI workflows share one approval process?
Use a consistent baseline, then scale review to consequences and sensitivity. A public summarizer and an autonomous financial workflow need different evidence.
Can procurement transfer all responsibility?
No. A vendor may protect its service while your organization still controls data access, connector scopes, workflow design, and deployment decisions.
How often should we reassess?
Reassess after meaningful changes and relevant incidents, with a periodic review appropriate to the workflow. A new tool or permission can matter more than a calendar date.