How Prompt Fencing Can Tackle Prompt Injection: Thoughtworks Explained

01Read the proposal as authenticated structure

The core idea in Thoughtworks’ article is to preserve trust and content-type metadata around segments as a prompt is assembled. Trusted assembly code applies the boundaries, and cryptographic authentication is intended to make unauthorized changes detectable. The published fence notation is illustrative, not a universal format that can simply be pasted into every model API.

That distinction matters because the term “fencing” can also refer informally to putting content between delimiters. An ordinary delimiter can improve clarity without proving who created the enclosed material. Authenticated structure aims to add evidence about origin and integrity as well as a visible boundary.

My recommendation is to ask what a proposed implementation actually verifies before calling it prompt fencing. A product that only adds opening and closing tags has a different security property from a trusted verifier checking signed metadata. The name should describe the mechanism, not substitute for one.

02Keep authenticity separate from trustworthiness

A valid signature can establish that a recognized key signed particular bytes. It does not establish that those bytes are accurate, harmless, or authorized to govern every task. A compromised contributor can sign a false statement, and an authorized source can provide information outside its permitted role.

Imagine a supplier document with a valid origin signature. It may be useful evidence about the supplier’s product, but it cannot authorize your assistant to send an internal report elsewhere. Authentication narrows the question of origin; it does not answer the business authorization question.

I would model those properties separately in a design review. Record identity, integrity, source role, data sensitivity, and allowed use as distinct fields. A single “trusted” flag is tempting because it is easy to display, but it can hide the difference between a known author and an instruction source with permission to direct the application.

03Apply labels before untrusted content can choose them

Trust metadata should be assigned through an application-controlled path. If a document can declare itself to be a system instruction and the assembler accepts that declaration, the label provides little protection. The source of the label matters as much as the source of the text.

For a practical ingestion design, I would maintain an inventory of source types and which component is allowed to classify them. A user upload can remain user-uploaded content even if its first paragraph claims administrative authority. A connector authenticating to a service should not automatically upgrade every returned record to policy.

Use explicit handling for missing or unexpected metadata. Decide whether to reject the item, keep it in a low-trust content role, or require review. Silently promoting unlabeled content because the pipeline needs to finish is exactly the sort of convenience decision that makes a boundary difficult to defend.

04Treat assembly and transformations as security-sensitive work

A multi-stage application may extract a PDF, split it into passages, summarize those passages, and combine the summaries with other sources. Every transformation changes what later components see. If metadata disappears during that process, the final prompt can lose the distinction the architecture was meant to preserve.

My implementation analysis would define how derived content is represented. A summary should refer to its input sources and should not inherit instruction authority just because an internal component produced it. When content bytes change, any integrity mechanism must account for the new representation rather than pretending the original signature covers an unrelated result.

Canonicalization, versioning, and verification rules need a precise specification. The application must know which content and metadata are protected together. A design that verifies one field while consuming another can create a misleading appearance of authenticity even though the model receives material outside the verified envelope.

Thoughtworks’ prompt fencing proposal distinguishes authenticated boundaries from semantic interpretation and identifies limits that remain after provenance is established.

05Verify with code rather than asking the model to guess

Cryptographic verification belongs in trusted software with controlled keys and defined algorithms. A model reading a signature-shaped string is not equivalent to a verifier checking it. The application should know whether verification succeeded before relying on the protected metadata.

Keep signing keys outside model-visible context and ordinary retrieved documents. Decide who can issue or revoke signing authority, how keys are rotated, and what happens when a signer is no longer trusted. These are operational requirements, not language-model capabilities.

I would begin with one documented verification boundary and test malformed, missing, altered, and expired inputs where the chosen scheme supports expiry. The useful result is an explicit application decision. Avoid a workflow that asks the same potentially influenced model to decide whether a piece of text looks like a valid security envelope.

06Keep execution policy outside the authenticated prompt

Even a correctly verified prompt segment should not directly grant a tool permission. The execution service needs the current user, permitted resource scope, operation, and any required approval. Those checks remain valuable when the model misunderstands a segment’s role or a legitimate source contains harmful guidance.

Consider a read-only research workflow. Authenticated provenance can help show which document supplied a recommendation, but the tool service should still reject an attempt to write a shared record. The absence of write authority is a concrete limit that does not depend on every semantic interpretation being correct.

My preference is to let fencing improve the evidence available to policy and audit systems while keeping those systems authoritative over actions. This avoids a fragile circular design in which the model reads a trust label, declares itself authorized, and then passes that declaration straight to an unrestricted executor.

07Evaluate behavior as well as signature handling

A verifier can pass all of its unit tests while the assistant still follows instructions in low-trust content. Conversely, a model may behave well on a small demonstration even though the envelope is not actually verified. The two properties require separate tests.

I would test integrity handling deterministically, then evaluate the model’s behavior with clearly labeled content and harmless unauthorized objectives. Include quoted instructions, conflicting source claims, transformed summaries, and normal documents. Record whether the boundary survived the complete workflow, including tools and persistent state.

Do not generalize a successful demonstration into universal prevention. Results depend on the model, prompt structure, source representation, and execution controls. The practical adoption question is whether the added provenance and checks improve your own workflow under realistic conditions without making ordinary tasks fail or become unreasonably difficult to operate.

08Account for overhead without inventing performance gains

Metadata adds material to process, and verification adds work to the request path. How much that matters depends on segment count, document size, caching, implementation, and the model interface. A projection in a proposal should not be presented as a measured result for an application you have not tested.

Measure end-to-end latency, token usage, verification failures, and normal task completion in a controlled pilot. Include the cost of maintaining keys and source classifications, not just the time of a single signature check. Operational complexity can dominate a small benchmark.

I would start with a high-value pipeline that already has clear source ownership. If the organization cannot explain which component creates authoritative instructions, adding authenticated wrappers may make the ambiguity more formal without resolving it. Provenance is most useful when the roles it records are deliberately defined.

For controls that do not depend on adopting a new envelope format, the personal prevention guide starts with limited authority and exact action review.

09Adopt the useful boundary without overselling the name

A sensible first step is an inventory of prompt segments: developer policy, user request, retrieved evidence, tool output, and derived summary. Identify who controls each segment and which operations it may influence. This work is useful even before a cryptographic fencing pilot exists.

Then decide whether your actual risk includes loss or forgery of provenance across assembly stages. If it does, an authenticated envelope may be worth evaluating. If the immediate weakness is an unrestricted send tool, fix that authorization problem first; signed content does not make an unbounded executor safe.

My final adoption criterion would be a demonstrable improvement at a named boundary. The verifier rejects altered inputs, the application preserves source roles, and the executor still enforces permissions when the model is influenced. That is a credible engineering outcome. Claiming that tags alone eliminate prompt injection is not.

10Common questions