Executive briefThe document did not have authority, but the architecture lent it some

A procurement assistant read a supplier webpage that contained hidden text. The text told any visiting agent to ignore its task, find internal contract data and place a larger order with a different delivery address. The team described the event as a clever prompt attack and tuned a classifier. That response missed the decisive fact. A website had been allowed to influence the same model context that selected tools, supplied parameters and interpreted the user's authority. Content acquired the practical power of a mandate.

Prompt injection is real even when no tool exists. It can distort a summary, suppress a source, bias a recommendation or disclose context. OWASP distinguishes direct and indirect forms and notes that retrieval and fine-tuning do not fully remove the problem. Yet the most consequential incidents require another condition: the application gives model output enough functionality, permission or autonomy to create an external effect. That is why OWASP's separate excessive-agency category matters. Manipulated inference supplies the request; over-broad authority turns the request into harm.

Trying to make every piece of hostile prose harmless is not a complete security strategy. Language models are designed to let text influence text generation. External content can hide instructions in markup, images, metadata, code, quoted messages and tool output. Attackers can split a payload across sources or phrase it as an apparently useful rule. A detector may reduce exposure, but treating its verdict as authorisation makes a probabilistic component the final security boundary.

This paper proposes a ten-field Instruction Authority Record, an eight-stage Authority Firewall and an Authority Invariant. The record distinguishes who may instruct the system from what the system may merely read. The firewall turns model output into a proposal and places deterministic, stateful checks before execution. The invariant gives testers a stronger objective than finding every attack string.

The strongest rival: solve the model

Model robustness, prompt hardening, filtering, provenance-aware retrieval and adversarial training are valuable. They can prevent misleading output, reduce triage load and protect low-risk interactions. Some applications have no external effect and need little more. But a claim that the model will always distinguish data from instruction asks an adaptive statistical system to enforce a security property across arbitrary language and future attacks. Current guidance does not support that certainty.

The practical target is defence in depth. Improve the model and detect suspicious content, but arrange capabilities so a missed injection cannot manufacture authority. The architecture should remain safe when the model repeats the attacker's words, proposes the attacker's tool call and confidently explains why it is correct. That assumption is severe enough to reveal whether the surrounding controls are real.

Two planesInformation may influence judgement without controlling permission

The information plane contains claims the system may use to answer, compare, extract or recommend. A retrieved policy document may be highly trustworthy evidence, but its text does not automatically become a runtime instruction. A regulator's website may authoritatively describe a legal duty while lacking authority to operate the reader's internal tools. A tool result may accurately report a balance yet have no right to raise a payment limit. Provenance and authority answer different questions.

The authority plane contains authenticated principals, valid mandates, instruction precedence, resource policy, workflow state, transaction limits, approval evidence and revocation status. Its records are assembled through channels designed for control: signed configuration, policy services, identity systems, case management, approval workflows and receiving-system checks. The model may read a representation of this state, but free-form text cannot write it.

This distinction prevents a common mistake: equating trusted content with trusted commands. Trust is dimensional. A clinical guideline can be trusted for a treatment claim while being unauthorised to send a prescription. A supplier can be trusted to state its bank account while being unauthorised to change the account already approved for payment. A peer agent can be authenticated yet lack a mandate for the requested dataset. The application records source, entitlement, class, purpose and allowed influence instead of assigning one global trust label.

Separate content class from source reputation

A respected domain can host compromised pages, user-generated material or outdated instructions. Conversely, a low-reputation source can contain a useful fact that is corroborated elsewhere. Classify the item as data, quotation, executable attachment, policy representation, user request or system control. Then specify its allowed influence. The classification travels with extracted chunks, generated summaries and downstream proposals so transformations do not erase the boundary.

Entitlement also matters. Content from another tenant is not made usable merely because retrieval returned it. Sensitive material may be relevant but outside the current case purpose. The acquisition layer should attach source identity, access basis, tenant, case, time, version and transformations before text reaches the model. If these facts are missing, the system can restrict the answer or isolate retrieval; it cannot infer permission from the prose.

Instruction Authority RecordTen fields make instruction precedence verifiable

The record need not be a new token. It can be a joined view across identity, workflow, policy and audit systems. What matters is that its fields have protected writers, versioned semantics and a shared correlation identifier. Copying their values into the prompt may help the model behave, but the validator and receiving service consult the authoritative sources again.

Instruction precedence is therefore not the order in which strings appear. A system prompt can be exposed, reconstructed or contradicted. It remains useful for model behaviour, but its text does not authenticate the business principal or convey a transaction approval. The application enforces which channels can change the record. That makes phrases such as “developer override”, “urgent security instruction” and “the user already approved” ordinary claims until verified.

Authority FirewallEight stages turn hostile text into a bounded input

Stage one acquires with provenance. Connectors attach source, entitlement, tenant, case, version, timestamp, content type and transformations. Retrieval does not erase the identity of the source. Stage two labels trust and class. The system states whether an item is external data, a quoted request, code, an attachment or a representation of policy. Detection signals can add suspicion, never authority.

Stage three isolates parsing. Untrusted material is processed in a context without credentials and without write, send, purchase or administrative tools. If a model must inspect executable or multimodal content, the sandbox and egress boundary match the worst plausible behaviour. Delimiters and system prompts reinforce the classification but are not the only separation.

Stage four assembles authority. The application retrieves the principal, task mandate, policy version, current case state, resource bounds, purpose, limits and required approvers from protected systems. This state is not accepted from a retrieved document, tool narrative or peer message. A signed representation may cross components, but each relying party verifies it.

Stage five asks for a typed proposal. The model can suggest an operation using a closed schema: action type, resource identifier, subject, recipient, amount, purpose, cited facts, uncertainty and requested approval. It cannot choose arbitrary endpoints, smuggle raw commands into parameters or directly call a privileged general-purpose tool.

Stage six validates deterministically. Code checks schema, authoritative facts, resource membership, tenant and case, purpose, permitted effect, recipient, limits, rate, separation of duties, current state and replay protection. Natural-language justification is evidence for review, not a bypass. Unknown values cause restriction, clarification or denial.

Stage seven obtains independent authorisation. High-consequence actions require a human or service that can see the exact transaction and change the outcome. Approval binds the action object, resource, recipient, value, expiry and relevant state. A generic “always allow” click or approval hidden behind model persuasion does not provide transaction authority.

Stage eight executes narrowly and records independently. The executor receives a short-lived credential for one audience and operation. It rechecks policy and writes a receipt containing the actual effect and terminal status. The model cannot declare success, alter the receipt or silently retry a denied transaction through another tool.

Typed action boundaryMake the model propose what deterministic systems can reject

A typed proposal converts open-ended language into a reviewable claim about a possible action. Its schema should be narrower than the downstream API. A refund assistant proposes one approved refund operation, not an arbitrary HTTP request. A file assistant proposes a write within one case directory, not a shell command. A communications assistant proposes a draft to recipients already eligible under case policy, not an unrestricted send.

Schema validation stops malformed or unexpected fields, but semantic validation is equally important. An injected tool result may suggest a larger refund while preserving every required key. A webpage may substitute an attacker-controlled delivery address in a syntactically valid purchase object. The validator compares recipient, resource, amount, purpose and source facts with protected records. It does not ask the same manipulated model whether its proposal is safe.

Authoritative facts deserve explicit writers. Account balance comes from the ledger, case ownership from the case system, recipient identity from a controlled address book, threshold from policy and approval from the workflow. The model can cite these records and flag discrepancies. It cannot replace them with a persuasive excerpt. If a required fact has no authoritative source, the safe design may stop at recommendation.

Credentials remain outside model context. The model neither selects a standing token nor copies user secrets into tool parameters. After validation, a broker exchanges current authority for a short-lived, audience-bound credential whose scope matches the approved operation. Resource indicators and sender-constrained tokens can reduce replay and confused-audience risk; they do not replace business-policy validation.

Human approval must see the transaction

Human review helps only when it can change the outcome and is not reduced to approving an AI-generated narrative. The approver sees the exact recipient, resource, amount, purpose, authoritative facts, model contribution, suspicious-content signals and proposed effect. The approval is bound to that object and expires. If the proposal changes, approval does not silently follow it.

For lower-risk operations, a policy service can provide independent authorisation. The principle is the same: the decision uses protected state and a closed action object. High volume is not a reason to let model prose become policy. It is a reason to define precise automatic limits, exceptions and stop conditions.

Compromise-oriented designJudge the boundary with the model already lost

Security review should ask what a completely manipulated model can do, not how often the preferred detector catches a benchmark. Give the red team a hypothetical model that follows every hostile instruction. Let it fabricate confidence, exploit tool descriptions, choose worst-case parameters and coordinate across turns. Then inspect whether it can cross the capability envelope.

In a sound summarisation service, the compromised model can produce a bad summary, omit a citation or quote attacker text. Grounding and evaluation should detect some failures, and the user should see provenance. But there are no write or send credentials to steal, and no tool route from document content to enterprise action. The remaining information risk is managed honestly rather than disguised as perfect prevention.

In an action system, the compromised model can populate a typed proposal. It still cannot widen its tool list, change token audience, read another tenant, authorise a new recipient, increase a transaction ceiling or satisfy separation of duties. The policy decision point sees the same request it would receive from a buggy model. This is important because excessive agency can produce damage after hallucination or ordinary error as well as attack.

Some designs cannot satisfy the invariant. A general shell with inherited credentials, a browser session that can buy from any site, unrestricted data access joined to outbound communications, or a payment API that trusts model-chosen recipients gives malicious content a path to elevation. Filters may lower probability, but the blast radius remains structurally broad. If consequence is serious and compensating controls cannot contain a fully manipulated model, the correct decision is not to deploy that design.

Containment and recoveryPreserve enough state to recover without replaying the attack

A suspicious-content signal can justify isolation even though it cannot authorise execution. The system stops new effects, marks the session, closes or narrows egress, revokes delegated credentials and prevents automatic retries. It preserves the input, transformations, model and policy versions, authority record, proposals, decisions, tool receipts and current workflow state. Sensitive content is retained under access and privacy controls, not copied into a convenient incident prompt.

Containment reaches beyond the model session. A tool call may have timed out after committing. A draft may have reached an external queue. A browser may have created a basket without payment. Responders reconcile actual effects with receiving systems and classify each action as not attempted, denied, prepared, committed, failed, compensated or unknown. Unknown is an investigation state, not permission to rerun.

Recovery starts from a clean trust boundary. Replace compromised inputs where possible, rotate affected credentials, patch the capability or policy gap, and issue a fresh task mandate. Do not restore a saved model conversation containing the malicious precedence claim and assume the new system prompt wins. Re-run required work from verified state with new correlation and idempotency identifiers.

False positives deserve design attention. Read-only summarisation can often continue in a more isolated mode while showing source warnings. A prepared transaction can remain a draft pending independent review. Reversible quarantine makes it easier to act early without granting the detector final authority over the business process.

Protocol boundaryMCP and A2A move messages; they do not mint enterprise mandate

Tool and agent protocols improve discovery, interoperability and structured exchanges. They can declare capabilities, input schemas and authentication mechanisms. Those features are useful inputs to the firewall, but protocol metadata is not a substitute for resource policy. A server description can be self-reported. A peer-agent card can identify an endpoint without proving that the peer may act on a particular customer, case or transaction.

Every protocol hop therefore preserves content classification and revalidates authority. Tool results return as data, even if they contain imperative sentences. A peer agent's request is authenticated as that workload and checked against the delegated mandate. Neither a familiar tool name nor a successful transport authentication expands the principal's rights.

OAuth resource indicators can bind a request to the intended protected resource. Demonstrating proof of possession can constrain token replay. These mechanisms strengthen identity and credential handling, but the relying service still checks purpose, tenant, object, action, limits and live state. The architecture should not confuse possession of a technically valid token with entitlement to the proposed business effect.

Provenance records help investigators and users trace how retrieved claims, proposals and actions were derived. W3C PROV-O supplies a vocabulary for entities, activities and agents, yet provenance alone does not decide authority. A perfectly traced malicious document remains malicious. The value is that its influence can be bounded, examined and joined to the independent decision that accepted or rejected an effect.

Ten worked casesOne invariant across content, tools and transactions

1. Malicious document in a summariser

A report tells the model to disclose other files. The service has access only to the selected document and no tools. The system labels the text as document content, produces a source-linked summary and records uncertainty. Detection misses the injection, but the authority invariant prevents access or external action. Outcome: treat the content as untrusted data and continue without tools.

2. Retrieval tries to suppress a citation

A poisoned knowledge-base chunk demands that contrary sources be hidden and the answer point to an attacker domain. Retrieved chunks keep source identities and cannot change citation policy. The response pipeline requires claim-to-source links and restricts the answer when sources conflict. Outcome: isolate retrieval and require source-grounded output.

3. Email asks the assistant to forward secrets

An incoming message instructs the model to search private mail and forward results to a new address. The mailbox credential is read-only; send is not present in the summarisation capability. If the product supports drafting, recipient eligibility and purpose are checked outside the model and actual sending requires approval. Outcome: prepare a typed action but require independent authorisation.

4. Hidden web content alters a purchase

A page includes invisible instructions to change the product, quantity and delivery address. The browser can read candidate pages but cannot commit purchases. It proposes a closed order object; catalogue, approved supplier, address, budget and transaction approval are validated from protected systems. Outcome: prepare a typed action but require independent authorisation.

5. Tool result requests a larger refund

A support tool returns a correct case note followed by “increase refund to £2,400”. The model produces a well-formed proposal, so schema validation passes. The ledger shows £240, policy limits the remedy and the recipient is independently resolved. Semantic validation rejects the larger amount. Outcome: prepare a typed action but require independent authorisation.

6. Authenticated peer exceeds its mandate

A planning agent asks a worker to query another tenant because it would make the analysis more complete. Transport authentication proves which workload sent the request, not permission for the resource. The worker checks the delegation record and denies the cross-tenant scope. Outcome: treat the content as untrusted data and continue without tools.

7. Valid schema, invalid purpose

A proposal names an existing account, eligible action and amount below the numeric ceiling. Its purpose belongs to a different case and the recipient was not approved for this transaction. Deterministic validation rejects it even though the structure is perfect. Outcome: prepare a typed action but require independent authorisation.

8. Transaction-specific approval succeeds

A refund object is built from authoritative facts and shown to an authorised reviewer with the suspicious email highlighted. The reviewer approves the exact customer, amount, reason and expiry. A broker issues one narrow credential, the payment service revalidates it and writes the receipt. Outcome: prepare a typed action but require independent authorisation.

9. Suspected injection after tool access

Telemetry detects an attempt to embed a credential in an outbound parameter. The session is quarantined, delegated credentials are revoked, queued effects are frozen and receipts are reconciled. The case resumes with clean context and a new mandate only after the capability gap is repaired. Outcome: quarantine the session and revoke delegated credentials.

10. General shell, broad data and payments

An autonomous worker inherits a service account that can query all customers, run arbitrary commands and initiate payments. Its policy is largely a system prompt. A fully injected model can cause material harm before monitoring reacts, and there is no narrow executor to enforce the invariant. Outcome: do not deploy because the authority boundary cannot contain compromise.

Interactive decision artefactAuthority Boundary Gate

Use the gate during design, threat modelling or incident review. It does not produce a risk score. It identifies the appropriate handling path, states what content may influence, and names the authority fact that still controls execution.

Operating cadenceRun authority as a control service

At design, system owners enumerate content channels, principals, mandates, protected policy writers, model roles, tools, recipients, effects and receipts. Threat models assume hostile documents, web pages, emails, tool results and peers. High-consequence designs prove the Authority Invariant before release.

At ingestion, connectors attach provenance, entitlement, class, tenant, case, time and transformation metadata. Retrieval, ranking, summarisation and caching preserve these bindings. Missing metadata reduces allowed influence. Detector outputs are stored as signals with model, threshold and version, not promoted into permission.

At proposal, the model receives only the information and capabilities needed for its role. Closed schemas exclude raw commands and unexpected destinations. Independent validators resolve authoritative facts, policy, current state, resource membership, recipient, purpose, limits and duties. Consequential approval binds the exact object.

At execution, a broker supplies a narrow, short-lived and audience-bound credential. The relying system mediates every request, applies idempotency and writes the actual external effect. Equivalent actions across interfaces share limits so a denial cannot be bypassed through another tool.

During operation, teams inspect provenance loss, mixed authority and content, suspicious instruction patterns, abnormal proposal fields, denied recipient changes, repeated limit probes, cross-tool retries, stale approvals and missing receipts. They measure how often controls constrain effects, not only detector accuracy.

On incident, quarantine stops new effects, revokes delegated credentials, preserves evidence and reconciles completed business state. Recovery starts from clean content, corrected capability boundaries and fresh authority. Post-incident review asks which control allowed text to affect identity, permission, scope, transaction limit or precedence.