Most AI agents in production today treat everything in their context window the same: a retrieved PDF, a memory note, a tool description and the user's own instruction all carry equal weight when the agent decides to send an email or write a file. On 6 October 2026 the USPTO granted US 12,755,049 B1, a patent that describes how to stop doing that by giving every piece of outside context an admission state before it can ever authorize an action.
AG Tech Consulting's advice for clients this week: list every source of outside context your agents read, mark each one as "context-only" or "can authorize actions," and add one check right before every write, send or credential use that re-confirms that decision.
The patent in one paragraph
US 12,755,049 B1 is titled "Untrusted context admission, derivation control, and effect-bound revalidation in agentic systems." The inventor is Yong Bok Lee of Sheridan, Wyoming, and the assignee is The Crown and the Cross LLC. Application 19/648,556 was filed on 15 April 2026, claims priority to a provisional from 10 March 2026, and was granted on 6 October 2026 with 30 claims.
It describes a governance platform that sits between outside content and the agent. That platform decides what each artifact is allowed to do, tracks that decision through every summary and plan made from it, and checks it again at the moment of any real-world effect.
How the mechanism works
1. Every artifact gets a record and an admission state
When an external context artifact arrives (a retrieved document, a memory item, a shared note, a tool description, a skill file), the platform creates an artifact record in a registry. The record stores an artifact identifier, a source class, a version or digest, and an admission state.
Machine-readable policy rules then set three properties. Provenance evidence covers source identity, signature status, digest match, repository origin, timestamp attestation or transparency-log reference. Mutability says whether the artifact is mutable, version-locked, append-only, immutable, pointer-based or mirrored from a mutable source. Trust tier ranks the source.
Those three feed an authority-eligibility status: may this artifact influence authorization of the specific operation the agent wants to run? The answer becomes one of four admission states: deny, quarantine, context-only or authority-bearing.
2. Three workspaces, and context-only cannot authorize
The artifact, or a transformed version of it, is placed in a quarantine workspace, a context-only workspace or an authority-bearing workspace. The agent only sees the workspace-selected version.
The central claim is simple: a context-only representation must not serve as an authority-bearing input. The agent can read it, reason over it and quote it. It cannot use it to justify a side effect. The quarantine workspace is kept apart from both the authority-bearing workspace and the policy logic itself.
Claim 7 adds a practical step. The context-only copy can strip out imperative instruction strings, executable code fragments, embedded credentials, capability descriptors and authority tokens. That is the patent's direct answer to indirect prompt injection.
3. Safe defaults for the riskiest sources
Claims 5 and 25 set a default: anything from an external memory store, a retrieved document source or a mutable shared document is context-only unless a verified policy authorization meets a promotion condition. In plain terms, RAG results and agent memory are untrusted by default.
Claim 14 allows different admission states for different fragments of one compound artifact. A ticket's structured fields from your system of record could be authority-bearing while its free-text description stays context-only.
4. Derivation control: restrictions follow the data
Restrictions on a source artifact carry over to anything derived from it: summaries, plans, translations, excerpts and tool argument packages. A summary of an untrusted email is still untrusted, unless a promotion condition is met.
Claims 10 and 20 cover presentation tricks. Excerpting, truncation, highlighting, reflow, translation or summarization cannot widen what an artifact is allowed to do. Authority is bound to selectors, fields and spans, not inferred from how text looks.
5. Relay envelopes: no privilege inflation between agents
When an artifact or a derived artifact is passed to another agent, tool, runtime or remote service, it needs a current authority capsule or relay envelope. That envelope must match the action class, recipient class, environment scope and trust-domain condition.
Claim 13 caps the delegated scope at the intersection of the upstream grant, the downstream local policy and the artifact's own use restrictions. A sub-agent can never end up with more authority than the chain that called it. If the request exceeds that scope, the artifact is denied, held, quarantined, downgraded or must be rewrapped.
6. Effect-bound revalidation at the execution boundary
An execution boundary gate intercepts the request just before a side effect. It rechecks the current version or digest, the admission state, mutability, trust tier, authority eligibility and policy state. If any of these has changed, the operation is blocked, downgraded or held.
Claim 19 lists the action classes: file write or deletion, queue insertion, schedule creation, message transmission, credential use, data disclosure, purchase submission, remote API mutation, physical actuation, and updates to a memory store, retrieval index, embedding store, policy store, training corpus or fine-tuning queue. The last group matters most: writes that change how the agent behaves in the future.
Claim 17 covers deferred work. For queued, scheduled, resumed or replayed operations, a live execution permit must still be valid at commit time, with revocation checks. Claim 30 extends the gate to browser agents: autofill, clicks, navigation, form submission and credential entry.
7. Receipts for audit
Each admission, relay, snapshot and execution-use decision produces a receipt or verifier output. An admission receipt records the artifact ID, digest, trust tier, authority eligibility, admission state and a reason code. Claim 29 makes it integrity-protected. That is the evidence trail an auditor or regulator will ask for.
Reading is not authorizing: how US 12,755,049 B1 governs untrusted context in an agentic system. An external artifact (retrieved document, memory item, shared note, tool description or skill file) is registered with provenance, mutability and trust tier, then admitted as deny, quarantine, context-only or authority-bearing. Each state maps to its own workspace, and context-only content (and anything derived from it) cannot authorize actions. At the effect boundary, a gate revalidates the version, admission, scope and policy before any file write, message, API mutation, credential use or memory write. It either lets the side effect run or blocks, holds or downgrades it, and issues a receipt for audit.
Why this lands now
The agent-framework advisories of the past week shared one root cause: model output and tool results were treated as if they were the developer's own trusted input. Patching each framework fixes each bug. It does not fix the design.
This patent describes the design fix. Separate "what the agent may read" from "what the agent may act on," keep that separation through every derived artifact, and check it again at the last moment before anything changes in the world. Its cited references include Greshake et al. on indirect prompt injection, Macaroons-style contextual caveats, OAuth DPoP (RFC 9449), Certificate Transparency (RFC 9162) and in-toto supply-chain attestations. It borrows proven ideas from authorization and software supply-chain security and applies them to agent context.
A note for builders: this is a granted patent with a named assignee. Before you copy its exact architecture into a commercial product, ask your counsel to review the claims. The underlying principles (least privilege, provenance, taint tracking, check-at-use) are long-standing security practice.
Future security risks to plan for
1. Memory poisoning that persists. One injected note written into long-term memory or a vector index steers every future session. The patent treats memory and index writes as effect boundaries for this reason.
2. Summary laundering. An untrusted email becomes a "clean" summary, then a plan, then tool arguments. Without derivation control, the original taint is lost two steps in.
3. Privilege inflation in multi-agent chains. A low-trust research agent hands work to a high-trust executor agent. Without relay envelopes, the executor's permissions quietly apply to attacker-supplied content.
4. Time-of-check, time-of-use gaps. A shared document is approved at 9 AM and edited at 9:05 AM, before a scheduled agent acts on it. Only digest checks at the execution boundary catch this.
5. Tool and skill file tampering. Tool descriptions and skill files are mutable, often fetched at runtime, and rarely signed. They are becoming the new software supply chain for agents.
6. Audit and liability pressure. When an agent sends the wrong payment or discloses data, "the model decided" will not satisfy a regulator. Organizations will need receipts showing which input authorized which action.
A 10-point checklist for CTOs
Inventory every external context source your agents read: RAG indexes, memory stores, shared drives, tickets, email, web pages, tool descriptions and skill files. Give each source a trust tier and a mutability label (mutable, version-locked, immutable) in a simple artifact register. Make retrieved documents, memory and shared documents context-only by default; write down the explicit promotion rules for anything that may authorize actions. Strip or neutralize instruction strings, code, credentials and tokens from context-only content before it reaches the model. Carry a taint label through summaries, plans and tool arguments so derived content keeps its source's restrictions. Put a deterministic gate, outside the model, in front of every file write, message send, API mutation, credential use and payment. At that gate, re-check the version or hash of every input that justified the action, especially for scheduled or resumed jobs. Treat writes to memory, vector indexes, prompts and fine-tuning data as privileged actions that need the same approval as an API write. For agent-to-agent handoffs, pass a scoped token that is never broader than the caller's own grant, and verify it on receipt. Log a tamper-evident receipt for every admission and every executed action, with a reason code your auditors can read.
The bottom line
Reading is not authorizing. US 12,755,049 puts a clear architecture around that idea: admit context with a state, keep the state attached to everything derived from it, and revalidate at the effect boundary. Whether or not you license anything, this is the right mental model for any agent that can change data, money or messages.
Sources: US Patent 12,755,049 B1, "Untrusted context admission, derivation control, and effect-bound revalidation in agentic systems," granted 6 Oct 2026, application 19/648,556 (The Patent Place IP Library, thepatentplace.com/iplibrary/patent-grant/12755049/); Exa patent library record (exa.ai/library/legal/patent/nyjwnzpykym); Greshake et al., "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection."
Want to map your agents' context sources and execution boundaries? Email avinash@agtechconsulting.ai, visit agtechconsulting.ai, or book a 30-minute call: https://calendly.com/avinash-dubey-30-min-catchup/meeting-with-ag-tech
Originally published on LinkedIn in the Your CTO Advisor newsletter: read and comment on LinkedIn →
