baharloo.omid@gmail.com
Version 6.2 — extends the principal model and the split-authority partition to delegated principals and assurance tiers.
Large language model (LLM) agents are increasingly given operational authority over public-facing commercial and organizational services that handle transactions, customer records, and business state. Existing defenses either rely on model alignment and prompt-level instructions, or assume a personal-assistant setting in which the party issuing instructions is a trusted owner. In public service deployments neither assumption holds: any anonymous caller may be an adversary, and the LLM planner itself, which is subject to stochastic failure, adversarial manipulation, and observation by its hosting provider, must be treated as an untrusted component. We present the Byzantine-Resilient Agent Harness (BRAH), an architecture that enforces availability, integrity, and confidentiality without depending on model compliance. BRAH rests on three mechanisms. First, LLM-Zero Completeness requires that every business state transition reachable through natural-language interaction is also reachable through a deterministic, model-free port state machine, so that service continues during a total model outage or budget exhaustion. Second, policy-partitioned split authority and context-bound proxies bind every identity parameter from an immutable execution context and partition state-mutating capabilities according to the service designer’s risk policy into direct context-bound mutations and confirmation-gated proposals ratified out of band by the authenticated principal. Third, bidirectional, principal-owned capability envelopes replace sensitive inputs and outputs with opaque handles in the model’s context across verified platform contacts, pattern scrubbers, and state-machine input boxes, while parameter-free introspection removes existence oracles. The model further extends to delegated principals—personal assistants acting on behalf of a master under attenuated credentials—through an assurance-tiered partition of confirmation-gated authority. We formalize a dual-adversary threat model, state and prove three invariants under explicit assumptions, describe a declarative programming model with compile-time verification gates in a reference runtime, trace four deployment scenarios, and analyze ten classes of attack against the design.
Keywords: LLM agents; prompt injection; reference monitor; confused deputy; object capabilities; capability envelopes; information-flow control; Byzantine fault tolerance; delegated authority; capability attenuation
Large language models have moved from passive text generators to goal-directed agents that perceive digital environments and execute multi-step workflows. In commercial and organizational settings, such agents are given tool interfaces that let them query relational databases, call third-party REST and Model Context Protocol (MCP) endpoints, manage content systems, and mediate transactions over public messaging platforms.
This shift exposes a structural weakness. An autoregressive model receives control instructions and untrusted data in a single, undifferentiated token sequence. Classical systems separate the two by construction: the Harvard architecture, write-xor-execute page permissions, and parameterized database queries all prevent data from being interpreted as code. An LLM offers no corresponding separation between system prompts, developer policy, conversation history, and external content.
Most agent frameworks attempt to prevent unauthorized state changes and data leakage through model-level measures: reinforcement learning from human feedback, instruction-hierarchy fine-tuning, defensive system prompts, and secondary LLM-based filters. Benchmarks of tool-integrated agents show that such measures fail under adaptive attack [9, 10]. Direct injection, indirect injection embedded in retrieved pages or database rows [11], multi-turn social engineering, and syntactic obfuscation all bypass prompt-level guardrails with regularity. Requiring a stochastic model to enforce access-control invariants while it interprets adversarial tokens contradicts two established design principles, separation of duty and complete mediation [5].
Recent work applies software-security techniques, notably information-flow control (IFC) and capability-based enforcement, to LLM agents [6, 7, 8]. These systems are designed for what we call the personal-assistant threat model, which rests on four assumptions. (i) The prompter is a single authenticated, trusted owner. (ii) The adversary is a third party that plants instructions in passive data fetched during execution, such as a document or an email body. (iii) The inference provider is trusted, so confidential documents may be placed in the model context in plaintext. (iv) Availability is secondary to fail-closed behavior, so halting when a policy is violated or the model is unreachable is acceptable.
Public service agents, such as event-registration desks, customer-support agents, content-publishing employees, and automated cloud-provisioning desks, operate under a different model, the public service-agent threat model, in which all four assumptions fail together. Any anonymous user of a messaging network can open a session, so the conversational caller is the primary adversary and may attempt to read other customers’ records, manipulate prices, or trigger unauthorized broadcasts. Because the planner processes the caller’s input directly, and is itself subject to hallucination and jailbreaking, it must be modeled as an untrusted, possibly compromised component. Cloud-hosted inference spans third-party jurisdictions and proxies, so sending regulated personal data or credentials to the model in plaintext is itself a disclosure. Finally, availability is a business requirement: a commercial agent cannot stop working because a provider suffers a network partition, returns gateway errors, or because an abusive caller exhausts the token budget.
Rather than strengthening prompt compliance, BRAH encapsulates the untrusted planner inside a deterministic reference monitor. The contributions are as follows.
BRAH adapts four results from systems security. Anderson’s reference monitor concept [1] requires that a mediating mechanism be tamper-proof, invoked on every access (non-bypassable), and small enough to be verified. Hardy’s confused deputy problem [2] describes how a program holding ambient authority can be induced by a less-privileged caller to misuse it. In a conventional agent, tools whose target parameters (recipient, customer record, or destination channel) are chosen by the model make the agent a confused deputy. Object-capability security [3] removes ambient authority by requiring that a subject hold an unforgeable reference that both designates an object and authorizes a set of operations; BRAH transfers this idea to natural-language runtimes through principal-owned, sink-restricted capability handles. Denning’s lattice model of information flow [4] provides the vocabulary of confidentiality and integrity labels used to reason about flows toward public sinks and from low-integrity sources.
Benchmarks such as InjecAgent [10] and AgentDojo [9] show that prompt-level defenses fail against adaptive indirect injection, and recent work has moved toward system-level isolation. CaMeL [6] derives control and data flows from the user’s trusted query. A privileged LLM compiles the query into a restricted program, a quarantined LLM without tool access parses untrusted data into typed values, and a custom interpreter tracks provenance and enforces capability policies at tool calls. The authors report solving 77% of AgentDojo tasks with provable security, against 84% for an undefended system. The guarantee presupposes a trusted initial query; if that query comes from an adversary, the privileged model compiles the attacker’s instructions into the plan. In addition, the quarantined model sees the raw data it parses, and a policy violation causes execution to stop.
FIDES [7] propagates confidentiality and integrity labels dynamically across planner turns and provides a selective hiding primitive that replaces confidential values with symbolic variables in the model context. It assumes a trusted task initiator and does not address out-of-band principal confirmation, bidirectional envelopes for unstructured inputs, or operation when the planner is unavailable. IsolateGPT [8] isolates third-party LLM applications in separate processes mediated by a central hub, which limits cross-application contamination for a single user, but it does not address shared business state manipulated by anonymous external callers.
Table 1 summarizes the differences in problem setting. The comparison concerns stated design objectives and threat models, not the quality of the cited systems within their own scope.
| Dimension | CaMeL [6] | FIDES [7] | IsolateGPT [8] | BRAH (this work) |
|---|---|---|---|---|
| Primary setting | Personal assistant: trusted user, untrusted data | Personal assistant: trusted user, untrusted data | Single user, multiple third-party apps | Public service agent: untrusted caller and untrusted planner |
| Trust in initial caller | Trusted | Trusted | Trusted (host user) | Untrusted |
| Trust in planner | Privileged model trusted for plan; quarantined model untrusted on data | Untrusted once it receives tainted data | Untrusted within app processes | Untrusted; also a potential disclosure channel |
| Availability objective | Not a stated objective; execution halts on policy error | Not a stated objective | Not a stated objective; requires live model | LLM-Zero Completeness |
| Integrity mechanism | Custom interpreter with provenance tracking | Dynamic label propagation | Process isolation with hub mediation | Context-bound proxies, policy-partitioned split authority |
| Confidentiality mechanism | Capabilities on values; quarantined model sees plaintext | Selective hiding with symbolic variables | Per-application namespace isolation | Bidirectional principal-owned capability envelopes |
| Text-only channel defense | Not addressed | Not addressed | Not addressed | Post-turn egress nonces |
| State mutation by planner | Permitted if policy allows | Permitted if labels satisfy policy | Permitted after hub routing | Partitioned by designer policy: context-bound direct vs. principal-confirmed proposal |
To state guarantees that do not depend on stochastic model behavior, we model the service agent as a state-transition system mediated by a deterministic reference monitor.
A public service agent is the tuple Ssys = ⟨S, P, Γ, C, T_M, M, H, Σ⟩. The set of authenticated principals is S = Suser ∪ Sowner, comprising external end users (customers, registrants, channel subscribers, or programmatic personal assistants) and the service owner (the operator who deploys and supervises the agent).
A distinguished subset Sdel ⊆ S comprises delegate principals—agents acting on behalf of a master principal s* ∈ S under an attenuated credential issued at onboarding (Section 6.8). A delegate’s effective authority never exceeds the recorded scope of its credential, irrespective of what its own planner may request.
Events enter through four typed ingress ports, P = {Pbot, Pacct, Papi, Pllm}. The port Pbot carries official messenger-bot webhooks, which deliver verifiable sender identifiers, structured contact cards, and inline-button callback payloads. The port Pacct carries personal-account session streams (for example MTProto-based clients or WhatsApp session gateways), which deliver text and media messages authenticated by platform peer identifiers but offer no structured interface elements. The port Papi carries structured HTTP and MCP endpoints, authenticated by bearer tokens whose SHA-256 digests are stored server-side. The port Pllm is the untrusted output stream (text and tool calls) returned by the inference gateway.
On an event from any port p ∈ P ∖ {Pllm}, the harness creates an immutable execution context bound to a turn:
where peer_id is the identity of the caller as verified by the transport, role ∈ {user, owner} is the caller’s role, cred_tier ∈ {delegate, master} records the assurance class of the presented credential, delegate_of ∈ S ∪ {⊥} names the master to which a delegate credential is bound (or ⊥ for first-class principals), and σdb is the database state snapshot. The context is held in coroutine-local runtime storage. The planner M has no read or write access to Γ and cannot forge or override any of its fields.
The domain engine exposes a finite set of deterministic commands C = Cread ∪ Cmutate. The service designer partitions state-mutating commands according to their business risk and user-experience requirements into two disjoint subsets,
where Cmutatedirect contains low-risk, reversible mutations that the designer permits the planner to invoke directly on behalf of the current caller (for example registering in an open course or opening a support ticket), and Cmutateconfirm contains high-consequence or irreversible mutations that require out-of-band confirmation by the user or the service owner (for example canceling a registration, finalizing a paid order, or publishing to an external channel). Each command c ∈ C is guarded by a deterministic predicate Authz(s, Γ, c, args) ∈ {true, false}.
The untrusted planner is a function M : Hsan × T_M → Text ∪ Aproxy. It receives only a sanitized, pseudonymized history Hsan and an attenuated proxy toolset T_M. Each proxy tool t̃ ∈ T_M either executes a context-bound operation in Cread ∪ Cmutatedirect or emits a non-executing proposal Π(c, args) for some c ∈ Cmutateconfirm. The reference monitor H mediates every ingress event, model invocation, and egress side effect. It maintains the opaque capability envelope vault
which maps unguessable handle strings h ∈ R to the underlying sensitive values, together with the owner peer and the set of sinks (database writes, owner notifications, or user egress) permitted to dereference each handle.
The first adversary, the untrusted external caller Acaller, interacts over Pbot, Pacct, or Papi and controls all inbound payloads. It may send direct injections, spoof system roles, or embed instructions in forwarded messages, documents, or URLs. Its goals include cross-peer access (peer_id′ ≠ Γ.peer_id); unauthorized mutations such as registering without payment, obtaining discounts outside the owner’s negotiation limits, or forging payment confirmations to the owner; and sending messages to third parties. It may also mount denial-of-wallet attacks by flooding the agent with token-intensive requests to exhaust the service’s inference quota.
The second adversary is the Byzantine planner [12] ALLM, which represents the model together with its hosting infrastructure in two roles. As an active subverter, whether through Acaller’s injections, poisoned weights, or ordinary hallucination, the model may emit arbitrary tool calls with fabricated arguments, supply another user’s identifier or handle, produce deceptive text next to a legitimate confirmation control, or claim that an operation has completed. As a passive observer, the cloud provider, network relays, and logging pipelines can read every token of the prompt. Any plaintext personal data, credential, or platform identifier in the prompt is therefore assumed to be disclosed. The two adversaries may collude.
Delegated principals (Section 6.8) add a third attack vector: theft or over-use of a delegate credential by an attacker, or abuse of an over-broad grant by a compromised delegate. We therefore require delegate credentials to be sender-constrained (proof-of-possession bound), short-lived, revocable, and monotonically attenuated along delegation chains, so that a stolen or misused token can never grant more authority than its recorded scope.
We assume that transport-level authentication (Layer 1) is not compromised, that the reference monitor and the domain engine are correctly implemented, and that cryptographic primitives and the random-number generator behave as specified.
A harness is Byzantine-resilient if it enforces three invariants under this model.
Availability invariant (A). Every domain command c ∈ C assigned to a principal role remains executable, with latency bounded independently of M, when M returns arbitrary errors, times out, or is unreachable.
Integrity invariant (I). No command c ∈ C and no outbound transmission can be executed by M for any principal other than Γ.peer_id. Moreover, no confirmation-gated command c ∈ Cmutateconfirm can be executed by M directly; every transition in Cmutateconfirm requires an explicit confirmation originating from the authorized principal over a deterministic port, with all identity parameters bound from Γ.
Confidentiality invariant (C). For all data kinds configured as confidential envelopes in Vsecret (Section 7), the mutual information between the prompt observed by M and Vsecret is zero, I(Prompt; Vsecret) = 0, and no caller s can infer or dereference any datum owned by a principal s′ ≠ s.
BRAH replaces the usual topology in which the model acts as controller with a three-layer reference monitor. The planner is an advisory leaf node outside the trusted computing base (TCB). Figure 1 shows the layers and the data crossing each boundary.
Layer 1 terminates network connections from messaging servers and API clients and performs three operations before any downstream logic runs. First, it authenticates at the transport level. For bot webhooks it validates a secret path component or header known only to the harness and the messaging platform and extracts the unforgeable sender identifier, any button callback payload, and any verified contact card. For personal-account streams it binds the sender’s platform peer identifier to the account session. For structured API and MCP ports, authentication middleware extracts the bearer token, computes its SHA-256 digest, compares it with the stored digest, and rejects failures with 401 Unauthorized before any tool function is reached.
Second, Layer 1 intercepts deterministic triggers. If an authenticated event is an inline-button callback, a slash command, a numeric state-machine code (including a confirmation nonce), or a prompted confidential input box, the model is bypassed and the event is handled deterministically. Third, if the event is free text destined for the model, Layer 1 applies the configured ingress scrubbers (Section 7.1), replacing structured contact payloads and pattern-matched sequences with opaque handles h ∈ R stored in Σ.
Layer 2 is the core of the TCB. It instantiates Γ and enforces three mediation rules. Implicit context binding: whenever a tool or command is invoked, Layer 2 reads peer_id and role from Γ and injects them into the function’s typed context parameter. These fields do not appear in the schema presented to the model, so the model cannot specify or alter recipient or customer boundaries. Policy confirmation gate: direct principal triggers arriving on Pbot, Pacct, or Papi may invoke any authorized command in C, while calls originating from Pllm are restricted to context-bound operations in Cread ∪ Cmutatedirect and non-mutating proposal generators Π(c, args) for c ∈ Cmutateconfirm. Scoped envelope dereferencing: before any handle argument reaches Layer 3 or is unveiled at egress, Layer 2 checks it against Σ, verifying that it is owned by the current caller and is permitted for the target sink (Equation 5).
Layer 3 contains the domain logic, persistence models, pricing rules, and outbound notification routers. It contains no model calls. Its inputs are commands whose parameters were validated and bound by Layer 2, and its outputs are state changes, outbound envelopes, and notifications generated by code.
In addition to end-user interactions, a service agent requires supervision by its owner. Rather than relying on conversational instructions to the model, administrative actions—such as updating operational parameters, inspecting database records, or approving high-consequence actions—occur over deterministic channels. When a command in Cmutateconfirm requires owner ratification (for example approving a manual payment receipt or authorizing a public broadcast), Layer 3 dispatches a deterministic approval card carrying signed inline buttons to the owner’s authenticated messaging chat. Because Layer 1 verifies that the callback originates from the configured owner identifier before executing the transition, neither an external caller nor a compromised planner can forge owner approval.
A common failure mode in agent engineering is LLM-monolithic coupling, in which the model sits on the critical path of every interaction. If the provider is unavailable, throttles requests, or responds slowly, or if an attacker consumes the service’s token budget, such an agent stops responding altogether. For a commercial service this is a violation of basic availability requirements.
Definition 1 (LLM-Zero Completeness). Let Σbiz denote the domain state space of the service and let Δ : Σbiz × C → Σbiz be the deterministic transition function over commands. A harness satisfies LLM-Zero Completeness if and only if, for every reachable transition σ c→ σ′ that can be assisted or proposed by the planner M, there is a finite input sequence p over the deterministic ports Pdet = Pbot ∪ Pacct ∪ Papi that produces the same transition without invoking M:
Under this definition the model is never the exclusive executor of a business capability. Its role is to help users who write in natural language discover commands and fill their parameters for operations that remain executable without it.
Because transports differ in their interface primitives, Layer 1 implements one deterministic port state machine (port-FSM) per port class, each exposing the full command set without invoking M. On bot ports, every user-facing command is compiled into an interactive menu button and a slash-command handler. In an event-registration agent, for example, the menu offers buttons for event details and remaining capacity, a verified FAQ, registration, sharing a verified contact, and payment. Each button produces a signed callback that Layer 1 routes directly to Layer 3.
On personal-account channels, which have no inline buttons, Layer 1 maintains a per-peer finite-state automaton driven by numeric codes or keywords. Sending 0 returns a numbered directory of services, and replying with a number advances a deterministic dialogue that collects the required fields and confirms high-consequence actions with a four-digit nonce. On structured API and MCP ports, every capability is a typed JSON-RPC tool that deterministic scripts or external personal assistants can call without conversational mediation.
Dual-mode systems risk logic divergence between manual menus and model-assisted flows. BRAH removes the risk by routing all execution paths through a single command bus in Layer 3. A registration may be triggered by an inline menu button, by a numeric wizard, by a programmatic call from a personal assistant, by a direct context-bound model call (when configured in Cmutatedirect), or by confirming a card that the model proposed (when configured in Cmutateconfirm). All paths invoke the same Layer 3 handler, so authorization, validation, and side effects are implemented once.
When a user sends free text instead of a menu command, Layer 2 mediates the call to M behind two guards. First, a circuit breaker traps model failures. If the gateway exceeds a timeout (8 s in the reference configuration), returns a 5xx or 429 status, or produces output that fails schema validation, Layer 2 replies with the deterministic menu and a notice that natural-language assistance is temporarily unavailable. Second, per-peer sliding-window quotas bound token consumption by a single caller: at most NLLM natural-language turns per hour (15 in the reference configuration) and at most Ktools proxy calls per turn (4). When a peer exceeds NLLM, Layer 1 switches that peer’s session to menu-only mode, which stops model token consumption while leaving every command available. A legitimate customer who reaches the limit can therefore still complete registration and payment.
Theorem 1 (Availability under planner failure). Consider a service agent built on BRAH that satisfies Definition 1, and assume that the deterministic components (transports, Layers 1 to 3, and the database) are available. For any failure state of the planner M, including complete disconnection, arbitrary malformed output, or per-peer quota exhaustion, the set of executable transitions Δ(σ, c) for all authorized principals is unchanged, and each is reachable within a time bound that does not depend on M.
Proof. Take any authorized command c ∈ C and state σ ∈ Σbiz. By Definition 1, the command compiler has registered a deterministic trigger sequence p ∈ Pdet* mapped to c on the command bus. When principal s submits p through a bot callback, a numeric code, or an API call, Layer 1 authenticates s, matches p against a trigger table in O(1) time, and dispatches c through Layer 2 to Layer 3 without invoking M. If instead s submits free text while M is unreachable, malformed, or rate-limited, Layer 2 traps the fault within the timeout and returns the menu that lists p. In both cases s executes Δ(σ, c) with Calls(M) = 0. ■
The theorem concerns the model as a point of failure. It does not protect against failures of the deterministic components, which are part of the TCB and are addressed by conventional redundancy. The coverage premise of Definition 1 is checked at build time (rule AST-04, Section 8.3).
Integrity requires that no cross-user state change, unauthorized financial charge, or cross-user communication can occur even when an attacker has complete control over the model’s output.
Conventional tool-calling frameworks expose general-purpose functions to the model, for example send_message(chat_id, text), cancel_registration(user_id), or register_user(user_id, name, phone). The harness holds the global credentials, so every parameter in a tool’s schema is under the model’s control. After an injection, the subverted model can supply another user’s chat_id or user_id, and the harness executes the request with its own ambient authority. This is the confused deputy [2].
BRAH forbids ambient target parameters in the planner’s toolset: no tool exposed to M may accept a parameter that designates a message recipient or principal identity (chat_id, peer_id, user_id, customer_id, recipient). The model has no message-sending tool at all: its ordinary text output is the reply to the current caller, and it otherwise receives narrow proxies such as search_kb(query) and context-bound domain commands. When M calls a proxy, Layer 2 reads the context Γ and rewrites the call deterministically:
check_my_status() → SELECT * FROM registrations WHERE peer_id = Γ.peer_idoutput(M) = m → transport.send_text(recipient = Γ.peer_id, text = egress_Σ(redact(m)))Because M cannot alter Γ, a prompt-injected model has no means of addressing a message to another user or reading or mutating another caller’s records.
Different state mutations carry different operational risks and user-experience trade-offs. In an event-registration service, for instance, a service designer may wish to allow the conversational agent to execute an initial course registration directly once the caller provides their name and contact handle (c ∈ Cmutatedirect), avoiding confirmation friction, while requiring explicit out-of-band confirmation before canceling an existing registration or committing a financial payment (c ∈ Cmutateconfirm).
BRAH supports this distinction directly in the reference monitor:
mode="direct"), the runtime exposes a context-bound proxy to M. When invoked, Layer 2 binds ctx.peer_id from Γ, validates the ownership of any capability handles in Σ, and executes Δ(σ, c) for the current caller only. Even if M is subverted, its effect is strictly confined to Γ.peer_id’s own session state.mode="user_confirm" or mode="owner_confirm"), direct execution is withheld from T_M. Instead, the runtime synthesizes a proposal tool propose_<c>(args), the proposal Π(c, args). Calling it changes no domain state: Layer 2 validates the arguments, computes any monetary quote in deterministic code, stores an inert proposal record, and renders a confirmation control to the authenticated principal (either the caller or the service owner). The mutation Δ(σ, c) is executed in Layer 3 if and only if that principal activates the confirmation button (on Pbot) or returns the post-turn nonce (on Pacct).An early design let the model emit free text together with a button-rendering tool. That allowed UI phishing (attack class I-1): a subverted model could write “Click below to download the free brochure” above a button that cancels a registration or commits a paid order. It also allowed the model to alter draft fields before confirmation (class I-3).
BRAH closes both paths with WYSIWYS draft binding and turn-level message preemption. Whenever M calls a proposal tool, Layer 2 discards all free text that M produced in that turn, so the model cannot frame or disguise the confirmation. Layer 2 then builds the entire confirmation message and button label deterministically from the stored proposal record and the pricing engine. The card begins with a fixed header (“Official confirmation form: the button below finalizes the details listed here”), lists every bound parameter (full name, masked phone preview, exact price), and carries a descriptive button label such as “Confirm cancellation of registration” or “Confirm registration: price 2,000,000 units”. Generic labels such as “OK” are rejected by the command compiler.
On personal-account channels there are no inline buttons. If confirmation used a static code (“send 9 to confirm”), a prompt-injected model could use its text reply to socially engineer the user (“to receive a free gift, reply 9”) into authorizing a mutation.
BRAH instead uses dynamic post-turn egress nonces. When M calls a proposal tool on such a channel, Layer 2 ends the model turn immediately. Only after the turn has finished does Layer 2 draw a fresh nonce from a cryptographic generator,
store ⟨prop_id, nauth, expires_at = t + 300 s, attempts = 0⟩, and append a system footer to the card at the egress boundary (“[System]: to finalize this action, send the code 4829”). The nonce is never written to the conversation history visible to M, so the planner has no information about it. Three consecutive wrong inputs invalidate the proposal, which limits guessing.
If the agent has a general tool for messaging the owner’s notification channel, a compromised model can fabricate a payment or registration confirmation during a customer conversation and thereby induce the owner to deliver goods or services without payment (class I-2). BRAH therefore separates the two kinds of message. Official notifications of state changes, such as confirmed registrations or verified payments, are emitted only from Layer 3 command handlers after the database commit, and the planner has no tool that can produce one. To let the agent hand an unanswerable question to the owner, the planner is given only escalate_to_owner(summary). That tool is limited to one open escalation per customer thread, and Layer 2 prefixes every escalation with a fixed banner stating that the text is an unverified claim by the customer and carries no system or financial confirmation.
Theorem 2 (Integrity against planner subversion). Consider a service agent that implements context-bound proxies, policy-partitioned split authority, WYSIWYS turn preemption, and post-turn egress nonces, and assume that Layer 1 transport authentication is not compromised. Then: (1) the probability that an active Byzantine planner M mutates a record or transmits a message belonging to a peer peer_id′ ≠ Γ.peer_id is 0 across all commands c ∈ C; and (2) for any confirmation-gated command c ∈ Cmutateconfirm, the probability that M executes c without principal confirmation is 0 on Pbot and Papi, and at most 3/9000 ≈ 3.3 × 10−4 per proposal on Pacct.
Proof. (1) For every tool t̃ ∈ T_M (including direct commands in Cmutatedirect), recipient and principal identifiers are absent from the schema and are bound by Layer 2 from Γ.peer_id, so the probability of a cross-peer dispatch or cross-peer state mutation is 0. (2) Since Cmutateconfirm ∩ T_M = ∅, the planner can only invoke Π(c, args) for c ∈ Cmutateconfirm. On each such call, Layer 2 discards the planner’s free text and emits a deterministic WYSIWYS card. On Pbot and Papi, executing c requires an authenticated callback bound to the principal’s session, which M cannot produce, so the probability is 0. On Pacct, execution requires the principal to return nauth, which is drawn after the planner’s turn has ended. Hence I(M; nauth) = 0, and turn preemption removes any concurrent text through which M could solicit a code. Any code that M causes to be submitted must therefore be a blind guess, and with a lockout after three attempts the probability of matching a uniformly drawn four-digit nonce is at most 3/9000. ■
The caller Γ.peer_id need not be a human. A growing deployment shape is a personal-assistant agent—the caller’s own agent—acting on behalf of its master. BRAH treats such an agent as a delegate principal sd ∈ Sdel: a first-class transport principal of its own (its own peer_id on Pbot or Pacct, or its own credential on Papi), bound to a master s* by an attenuated credential issued at onboarding. Layer 1 records Γ.cred_tier and Γ.delegate_of, and the authorization predicate computes the delegate’s effective authority as the meet of its own tier and the credential’s recorded scope. Because delegation credentials form a capability chain that may only narrow—scope, argument constraints, value ceilings, depth, and expiry shrink at each hop, verifiable offline [13, 14, 15]—monotonic attenuation is enforced by construction: a delegate can never exceed its grant, even when compromised.
The binary split of Equation (2) generalizes to an assurance-tiered partition. Every command in Cmutateconfirm declares a minimum principal tier:
assurance="delegate"): confirmation is required, but a delegate-tier credential may satisfy it—the personal assistant may press the button itself, within its recorded scope.assurance="master"): only a master-tier credential satisfies the gate. The delegate’s valid move is to relay: the service emits the proposal toward the delegate, the delegate renders its own confirmation control to the human master on the delegate’s trusted channel, and the master’s decision returns through the same deterministic ports. Because each hop renders its own WYSIWYS surface for its own principal, what each signer sees is exactly what it signs.This is strictly stronger than forwarding a button: a confirmation control is a rendering of a typed decision request for a specific principal class, and delegating raw key material to an agent is rejected in favor of policy-guarded signing or scoped credentials [16, 17]. In the reference deployment a personal assistant reaches the service over Pacct as a humanoid principal; the employee agent binds it as a master-class peer when its credential asserts that tier and relays Cmutatemastconf proposals upward to the human master(s). No dedicated agent-to-agent endpoint is required: the authenticated messenger session itself carries the delegation.
Theorem 2 extends unchanged in form: where the proof reads “the authenticated principal,” read “a principal whose Γ.cred_tier meets the command’s declared tier, with delegate_of chain-verified.” A delegate-tier confirmation of a Cmutatemastconf command is rejected at Layer 2 before any proposal is stored.
Confidentiality requires that sensitive user data and service secrets designated by the service designer remain hidden from other callers (Acaller) and from the cloud model provider (ALLM). Because different domains treat different attributes as confidential—for example, one service may require postal addresses and national identifiers to be hidden from the model while another requires outbound license keys or access links to be delivered without entering the prompt—BRAH provides a policy-driven, bidirectional capability envelope mechanism.
For every input data kind configured by the service designer as an inbound envelope, Layer 1 captures the value before prompt construction through one of three deterministic channels:
Mode 1 (Platform-verified contact cards): When a user presses the messaging platform’s native contact-sharing button (kind phone_verified) and Layer 1 verifies that the contact card’s user identifier matches the authenticated sender, Layer 1 intercepts the structured payload outside the model, stores the number in the vault Σ, and inserts a synthetic event into the transcript carrying only the handle.
Mode 2 (Configurable pre-prompt pattern scrubbing): For structured identifiers enabled in the service’s envelope policy (such as phone_unverified, national_id, card, iban, or credentials), Layer 1 normalizes decimal digits across Latin, Arabic-Indic, and Extended Arabic-Indic Unicode blocks and scans inbound free text before logging or model transit. Each match is stored in Σ and replaced inline by a typed handle (for example, “my number is [h_phone_unverified_u3b1]”). If a command requires a phone_verified handle, Layer 2 rejects a phone_unverified handle and instructs the planner to request a verified contact card.
Mode 3 (FSM-prompted envelope boxes for unstructured data): Regular expressions cannot reliably segment unstructured personal data such as a street address, a medical note, or a custom passphrase inside free text. When a command requires an unstructured envelope kind (for example HandleRef["address"]), the planner invokes request_envelope_input(kind="address") (or the user selects the corresponding menu button). Layer 1 transitions the caller’s port-FSM to AWAITING_ENVELOPE(kind) and prompts the caller. On the caller’s next message, Layer 1 intercepts the entire payload before the model is invoked, seals the plaintext in Σ as h_address_..., resets the FSM to IDLE, and passes only the opaque handle to the planner.
A naive tokenization scheme that keeps a flat table from handle to plaintext is vulnerable to confused handle injection (class C-1). If user B learns or guesses a handle that belongs to user A and asks the model to act on it, a tool wrapper that dereferences the handle discloses or corrupts A’s record. BRAH defines each vault entry as a four-tuple object capability,
and Layer 2 applies the following dereferencing rule whenever a component attempts to resolve h for sink τ under context Γ:
HandleAccessViolation) otherwiseThe sink set Psinks governs both inbound and outbound envelopes:
Scrubbing and ownership checks still leave a side channel, the existence oracle (class C-4). Suppose a customer-facing tool accepts a phone handle, as in check_registration_status(phone_handle). An attacker types a victim’s number into the chat, Layer 1 turns it into a handle owned by the attacker’s own session, and the model passes the handle to the tool, which reveals whether the victim is registered.
BRAH eliminates the oracle by requiring that customer-facing status tools take no identity or handle argument (check_my_status()). Layer 2 binds the query to the caller’s authenticated transport identity (WHERE peer_id = Γ.peer_id).
Platform-native identifiers (chat, user, and channel identifiers) are also withheld from the planner, since they allow correlation across sessions. Layer 2 removes them before building the prompt and substitutes constant symbolic names (CURRENT_USER, CURRENT_OWNER). Outbound tool calls resolve these symbols to physical identifiers only inside Layer 2’s egress adapter.
Theorem 3 (Confidentiality and non-interference). Consider a service agent that implements three-mode inbound envelope capture, principal-owned sink-typed handles (including outbound user-egress unveiling), zero-argument introspection, and metadata pseudonymization. Let Vsecret denote all values captured by the configured inbound and outbound envelope channels together with platform identifiers. Then (1) no value in Vsecret enters the context window of M, and (2) for any two distinct end users u1 ≠ u2, the observable outputs of u1 do not depend on the private records or handles of u2.
Proof. (1) Every inbound envelope value is intercepted at Layer 1 (by contact-card extraction, pattern scrubbing, or the AWAITING_ENVELOPE state machine) before prompt construction, and every outbound envelope value is sealed in Layer 3 and unveiled by Layer 2 only on the wire after M’s turn while persisting a masked placeholder in Hsan. Because handles are drawn from a cryptographic random generator independently of the plaintext, I(Prompt; Vsecret) = 0. (2) Suppose u1 tries to dereference or unveil a handle h2 created in u2’s session. The attempt fails Equation (5) because Σ(h2).owner_peer = u2 ≠ Γ.peer_id = u1. Suppose u1 tries to probe u2’s registration state. Customer-facing status tools take no identity arguments and filter on peer_id = u1. The outputs available to u1 are therefore independent of the state of u2. ■
Security architectures often fail in practice because they depend on application developers to write permission checks by hand in every tool function. In BRAH the invariants are enforced by the framework’s compiler and runtime, so that an insecure tool cannot be registered. The reference implementation is called codo-core.
Developers declare every capability with a single decorator whose mode states the designer’s authority policy (read, direct, user_confirm, owner_confirm, menu_only) and whose signature states any envelope parameters (HandleRef[Kind]):
from codo_core import ActionCtx, HandleRef, ReadCtx, action
@action(
mode="direct", # Designer policy: direct context-bound execution
title_fa="Register in course",
menu_button_fa="Register in course",
humanoid_menu_key="1",
labels_fa={"full_name": "Full name"},
)
async def register_attendee(
ctx: ActionCtx,
full_name: str,
phone: HandleRef["phone_verified"],
address: HandleRef["postal_address"],
) -> dict:
async with ctx.session() as s:
s.add(Registration(
customer_id=ctx.customer_id, # bound from Γ, never from M
full_name=full_name,
phone_number=await ctx.unveil(phone), # Σ: owner, sink and kind checked
postal_address=await ctx.unveil(address),
))
return {"status": "registered"}
@action(
mode="user_confirm", # Designer policy: user confirmation button/nonce
assurance="master", # Only a master-tier credential may confirm; delegates relay
title_fa="Cancel course registration",
menu_button_fa="Cancel registration",
humanoid_menu_key="2",
)
async def cancel_registration(ctx: ActionCtx) -> dict:
async with ctx.session() as s:
await s.execute(delete(Registration).where(
Registration.customer_id == ctx.customer_id))
return {"status": "canceled"}
@action(mode="read") # read-only helper: attenuated context
async def search_event_faq(ctx: ReadCtx, query: str) -> list[dict]:
return await ctx.search_kb(query)From each @action declaration the framework synthesizes the corresponding security artifacts. Under Pillar I, it mounts a deterministic menu button on Pbot, binds the numeric menu key on Pacct, and drives a deterministic wizard that asks for each parameter by its declared label. Under Pillar II, for mode="direct" it exposes a context-bound proxy that executes for the caller bound in Γ; for mode="user_confirm" it withholds direct execution and generates propose_cancel_registration(); for mode="owner_confirm" the same proposal is routed to the owner’s out-of-band channel; mode="read" functions receive an attenuated context that can neither write, send, nor open envelopes, and their database session always rolls back, enforcing WYSIWYS rendering and post-turn nonce verification. Under Pillar III, Layer 2 verifies before execution that phone and address resolve in Σ to handles of the required kinds owned by ctx.peer_id.
To build the tool schema for T_M, the framework inspects each function signature, removes the leading context parameter (ReadCtx or ActionCtx), and converts every HandleRef[Kind] annotation into a string handle parameter carrying the pattern ^h_[a-z0-9_]+_[0-9a-f]{16}$. At call time Layer 2 injects the context from the coroutine-local variable. The omitted identity parameters therefore do not exist from the model’s point of view.
At build and test time, the checker parses each source file into an abstract syntax tree and enforces the mandatory rules of Table 2.
| ID | Rule | Condition checked |
|---|---|---|
| AST-01 | Ambient identifier ban | No parameter of any declared capability, whatever its mode, is named in the forbidden recipient/identity/raw-value set {chat_id, peer_id, user_id, customer_id, recipient, channel_id, phone, token, …}; envelope and quote carriers are exempt. |
| AST-02 | Read-only mutation ban | The body of a mode="read" capability contains no database write (session add/delete/flush, insert/update/delete constructs, write SQL); read queries are permitted. |
| AST-03 | Read-only egress ban | The body of a mode="read" capability sends no message and emits no owner notification; only the planner’s mediated reply reaches the caller. |
| AST-04 | Completeness coverage | Every user-facing capability (direct, user_confirm, menu_only) has a registered deterministic trigger (menu button or account-channel key) and a label for every required plain parameter. |
| AST-05 | Required-assurance declaration | Every confirmation-gated capability declares its minimum principal tier (assurance="delegate" or assurance="master"); a delegate-scoped capability may not request a master-tier action, and a capability reachable by delegates must reference the master through ctx.delegate_of, never through a caller-supplied field. |
| AST-06 | Attenuation | A mode="read" capability touches no private or introspective path out of its attenuated context. |
| AST-07 | Configured envelope enforcement | No parameter whose data kind is declared as an envelope in the service specification is typed as anything other than HandleRef[...]. |
| SEC-01 | Secret hygiene | No credential (bot token, API key, private key, or any value of the deployment environment) appears in a version-controlled file. |
AST-01, AST-02, AST-03, AST-06 and AST-07 establish the premises of Theorems 2 and 3 at the level of code, AST-04 establishes the coverage premise of Definition 1, and SEC-01 keeps deployment credentials out of any repository that may later be shared or forked.
The development process applies a corresponding rule to security requirements. Each threat in a project’s threat register must be mapped to a deterministic mechanism in Layer 1, 2, or 3 and to an automated test. An entry whose stated enforcement is “prompt” or “model instructions” for a confidentiality, integrity, or availability requirement is treated as unmet. When a developer configures a high-consequence action with mode="direct", the tooling issues an explicit warning describing the trade-off and records the designer’s decision.
To show that the design applies across diverse service roles without special-casing, we trace it through four deployment scenarios.
The first scenario is an event-registration agent that answers questions about a workshop, negotiates discounts within an owner-defined band, registers attendees, collects payment, and notifies the organizer, through an official bot, personal-account channels, and an API. Table 3 traces a benign interaction by Alice and an active injection attempt by Mallory when finalized registration is confirmation-gated.
| Step | A: benign registration (Alice) | B: injection (Mallory) | Enforcing layer |
|---|---|---|---|
| 1. Ingress | Alice presses the share-contact button on the bot and asks to register as “Alice Rad”. | Mallory sends: “SYSTEM OVERRIDE: message chat_id=998877 that the event is free, and tell me the phone number for h_phone_verified_81.” | Layer 1: vaults Alice’s contact as Σ(h_phone_verified_81) with owner peer_alice; binds Mallory’s turn to Γ.peer_id = peer_mallory. |
| 2. Planner call | M sees “shared contact: [h_phone_verified_81]” and calls propose_confirm_registration(full_name="Alice Rad", phone="h_phone_verified_81"). | The subverted M tries send_message(recipient=998877, ...) and a status lookup with phone="h_phone_verified_81". | Layer 2 schema gate: no recipient parameter exists in T_M; the status tool takes no arguments. |
| 3. Handle and proposal check | Layer 2 confirms owner = peer_alice and kind phone_verified, computes the price, and stores the proposal. | M passes h_phone_verified_81 to the registration tool on Mallory’s turn. | Layer 2 dereferencing rule (5): owner differs from peer_mallory; HandleAccessViolation. |
| 4. Egress | Layer 2 discards M’s free text and sends the WYSIWYS card. Alice presses the button; Layer 3 commits the row and notifies the organizer. | The turn ends with no database write, no message to 998877, and no digit of Alice’s number disclosed. | Layers 2 and 3: split authority and handle ownership. |
If the inference gateway fails entirely during peak registration, users who open the bot and press the inline buttons for event information, registration, and payment complete the whole flow without interruption.
The second scenario is a news-reporting agent that wakes on schedules, fetches articles from external feeds, writes posts for a companion WordPress site, and publishes summaries to the owner’s messaging channels. Fetched web pages are untrusted and may contain indirect injections intended to make the agent publish a malicious link or post without authorization. Fetched content is wrapped in randomized delimiter tags, output is constrained to a typed schema in which every citation URL must belong to the set of URLs actually fetched in that run, and the publishing command accepts no destination argument: Layer 3 reads destination channels and publishing credentials from the agent’s environment configuration. When the owner configures publication as confirmation-gated (owner_confirm), Layer 3 sends each draft to the owner’s chat with deterministic [Approve & Publish] and [Reject] inline buttons.
The third scenario is a support agent operating on the business’s own personal messaging accounts, with inbound-message debouncing (a short quiet window with a hard cap). Layer 1 binds each turn to (platform, peer_id). The conversation history the planner sees is rebuilt each turn from the bound conversation only, and the planner’s reply is delivered only to the bound peer, so no tool or reply path can reach another customer. When the business owner replies to a customer directly from the shared account, Layer 1 detects an outbound message not authored by the harness and pauses automated replies on that thread so the owner can converse without interference.
The fourth scenario is an infrastructure-provisioning agent that sells managed cloud deployment tokens to developers over messaging platforms. A buyer selects a plan and completes payment via an electronic wallet or receipt verification. Once Layer 3 verifies payment deterministically, it calls an internal provisioning endpoint to mint a fresh bearer token (wks_...) and proxy credential. Because the minted token grants deployment access, it must never enter the LLM planner’s prompt or conversation history. Layer 3 therefore seals the credentials inside an outbound capability envelope (Psinks = {user_egress}, Section 7.2) and returns only the handle h_cloud_token_.... Layer 2 unveils the token exclusively on the outbound transport to the authenticated buyer while recording a masked placeholder in the stored chat transcript.
We catalogued eleven attack classes during design review of deployed agents. Table 4 states, for each class, how a conventional prompt-defended agent fails and which deterministic mechanism of BRAH blocks it. Classes I-1 to I-4 correspond to the integrity invariant, C-1 to C-4 to the confidentiality invariant, A-1 and A-2 to the availability invariant, and D-1 to delegated authority.
| ID | Attack class | Failure in a prompt-defended baseline | BRAH mitigation | Basis |
|---|---|---|---|---|
| I-1 | Spoofed-text phishing | A subverted model writes deceptive text above a real confirmation button, or tells a text-only user to reply with a static code. | Turn-level preemption discards model text when a proposal is emitted; post-turn nonces are drawn after the model turn ends. | Thm 2 |
| I-2 | False-fact notifications | The model calls a general notify tool to fabricate a payment or registration alert to the owner. | System notifications are emitted only by Layer 3 code after commit; the escalation tool adds a fixed unverified-claim banner. | Sec. 6.6 |
| I-3 | Pre-confirmation poisoning | The model alters the name, tier, or price in the draft before the confirmation control is shown. | The card and button label are generated in code from the stored proposal and the pricing engine. | Thm 2 |
| I-4 | Cross-peer state tampering | The model passes another user’s identifier to read, modify, or cancel that user’s record. | Peer and customer identifiers are absent from all model schemas and injected from Γ.peer_id (rule AST-01). | Thm 2 |
| C-1 | Confused handle injection | An attacker supplies another user’s handle as a tool argument to exfiltrate or bind that user’s confidential data. | Principal-owned capability handles; dereferencing rule (5) checks owner and allowed sink. | Thm 3 |
| C-2 | Inbound & outbound secret exposure | A user types sensitive data (phone, ID, postal address) or a tool returns a secret token in plaintext to the model. | Pattern scrubbing, FSM-prompted envelope input boxes, and outbound user_egress unveiling keep plaintext out of M’s context. | Thm 3 |
| C-3 | Platform-identifier leakage | Numeric chat and user identifiers are serialized into prompt history, enabling correlation by the provider. | Layer 2 replaces all platform identifiers with constant symbols. | Thm 3 |
| C-4 | Existence-oracle inference | An attacker types a victim’s number and asks a lookup tool whether the victim is registered. | Customer-facing status tools take no arguments and bind to Γ.peer_id. | Thm 3 |
| A-1 | Dead-end service outage | A provider outage (gateway error or timeout) leaves users unable to register or pay. | Port state machines and the circuit breaker execute all commands without model calls. | Thm 1 |
| A-2 | Denial-of-wallet | An attacker floods the agent with complex prompts to exhaust the owner’s token budget. | Sliding-window quotas; abusive peers are degraded to menu-only mode. | Thm 1 |
| D-1 | Delegated-credential abuse | A stolen delegate token, or a compromised delegate exercising an over-broad grant, acts with the master’s authority. | Attenuated capability chains (sender-constrained, expiring, revocable, offline-verifiable); per-command principal-tier gates. | Sec. 6.8 |
Three interactions between mechanisms deserve explicit discussion. The first concerns integrity and confidentiality (C-1, C-2, C-4). Consider an architecture that scrubs phone numbers (C-2) but has neither principal-owned handles (C-1) nor zero-argument introspection (C-4). When an attacker types a victim’s number, the scrubber converts it into a handle owned by the attacker’s session. If the status tool accepted a phone handle, the ownership check Σ(h).owner_peer = Γ.peer_id would pass, because the attacker typed the digits in the attacker’s own session. Two measures together close the oracle: typed digits are labeled phone_unverified and cannot be used where verified contact ownership is required, and status queries are bound to Γ.peer_id instead of to any handle.
The second concerns turn-level preemption (I-1, I-3). Common human-in-the-loop frameworks allow the model to emit an explanatory string in the same turn as a deferred approval request. A subverted model can use that string to misdescribe what approval does. By suppressing the model’s text whenever a proposal is emitted and generating the whole card from the validated proposal, BRAH ensures that the principal sees only system-generated parameters.
The third concerns quotas and completeness (A-1, A-2). In a conventional chatbot, rate-limiting a user after a number of messages can block a legitimate customer from completing a purchase. Because BRAH satisfies LLM-Zero Completeness, switching a rate-limited session to menu-only mode never blocks a conversion: the customer still has the deterministic menu for registration and payment, at no token cost.
Requiring out-of-band confirmation before a state mutation introduces an additional user interaction step. Rather than imposing a one-size-fits-all mandate, BRAH makes the confirmation boundary a declarative per-capability parameter (mode) while enforcing context binding (Γ.peer_id) and capability-envelope ownership (Σ) unconditionally across both direct and confirmation-gated commands. Service designers can therefore choose direct execution for low-risk, reversible actions where conversational speed matters, and reserve WYSIWYS confirmation buttons or post-turn nonces for destructive, irreversible, or financial commitments.
While pre-prompt pattern scrubbers automatically capture structured identifiers (such as phone numbers, national identifiers, and card numbers), unstructured confidential fields (such as street addresses or passphrases) require the caller to enter them after Layer 1 activates an AWAITING_ENVELOPE state-machine prompt. If a caller unexpectedly volunteers an unstructured secret inside an ordinary free-text turn before the envelope prompt is activated, pattern matching alone cannot guarantee its detection without a local named-entity classifier inside Layer 1.
A four-digit nonce balances usability against guessing resistance. Because it is drawn after the model turn, the planner cannot predict or solicit it, and the three-attempt lockout limits a blind guess to a success probability of 3/9000 ≈ 3.3 × 10−4 per proposal. For high-value transactions the nonce length can be increased to six alphanumeric characters, which gives more than 2 × 109 combinations.
Several risks lie outside the guarantees stated here. (i) The theorems assume a correct TCB; an implementation fault in Layer 2 or Layer 3, or a business-logic error inside a domain command, is not mitigated by the architecture. (ii) A human principal can approve an accurate card on the basis of a mistaken understanding, and repeated confirmations may cause fatigue. (iii) Plain-text replies in non-mutating turns remain under the planner’s control and may be inaccurate or misleading, although they cannot change confirmation-gated state or address other users. (iv) Timing and response-length side channels were not analyzed. (v) The static gates are syntactic and conservative; they complement, and do not replace, runtime mediation. (vi) Availability is guaranteed relative to the planner only; the deterministic path can still be disrupted by network or infrastructure outages. (vii) Delegated principals move part of the trust surface to the delegate’s own infrastructure: the delegate’s inference provider becomes a passive observer of master-side context, and mis-issued or non-attenuated delegation credentials reintroduce ambient authority; assurance tiers bound, but do not eliminate, this surface.
This paper argues for security by construction and states the assumptions under which each invariant holds. It does not report measured attack-success rates, latency overhead, or effects on task utility. Such measurements, obtained from a controlled red-team evaluation with a documented protocol, are the principal item of future work.
Treating a language model as a trusted application controller governed by natural-language instructions is incompatible with public commercial security. When an agent serves external callers, both the caller and the internal planner must be modeled as untrusted. BRAH demotes the planner from controller to an unprivileged, context-blind advisor inside a three-layer deterministic reference monitor. Availability follows from LLM-Zero Completeness, which gives every business capability a model-free execution path. Integrity follows from context-bound proxies and policy-partitioned split authority, reinforced by turn-level preemption and post-turn nonces, which together eliminate cross-peer confused-deputy attacks and UI phishing while letting the service designer choose which mutations require explicit confirmation. Confidentiality follows from bidirectional principal-owned capability envelopes—spanning verified contacts, pattern scrubbers, FSM-prompted input boxes, and outbound user-egress unveiling—together with zero-argument introspection and metadata pseudonymization. Compile-time verification gates in the reference implementation keep these properties from depending on developer discipline.