AI Security Is About Authority, Not Just Sandboxing

02 · Product and marketing promise

Give agents capabilities—not access.

“Our AI is secure” is not a useful product promise because buyers cannot see what it means. Does it mean the model provider encrypts traffic? Does it mean the application filters prompts? Does it mean a tool runs in a container? Does it mean a human is somewhere in the loop? Does it mean the agent can still read every record and call every internal API?

A better product story is concrete:

• Private information stays inside the selected boundary unless an explicit route requires disclosure.
• Every agent receives a small, named set of capabilities instead of ambient application access.
• Retrieved text remains evidence—even when it contains instructions.
• Important actions are revalidated outside the model against current identity, evidence, policy, state, and approval.
• Denied, stale, duplicate, conflicted, and unverified outcomes remain visible.
• A receipt records what was allowed, what actually happened, and what proved the result.

That story is more memorable because it turns security from an invisible infrastructure claim into part of the product experience. A user can see that a document stayed local. An operator can see why an agent cannot dispatch a shipment. A reviewer can see that approval expired after the target state changed. A game developer can see that an intelligent rival cannot invent a movement verb or bypass collision. A government team can preserve the original record and the exact authority behind a derived revision.

Prompt injection can shout. It still cannot sign.

The phrase captures the architectural goal. Malicious content may influence a probabilistic model. It should not be able to mint identity, expand permissions, create a capability, rewrite policy, bypass approval, or commit official state.

03 · Business and executive case

Security architecture is what turns an impressive agent demo into an adoptable product.

Organizations do not reject agentic AI only because models make mistakes. They reject it because responsibility becomes unclear. If an agent reads the wrong tenant, leaks a private attachment, issues the same credit twice, executes after an approval expires, or describes an incomplete operation as successful, the question is not merely “Why did the model say that?” The question is “Why did the surrounding system allow it to matter?”

A mature security and authority architecture creates an operating model leaders can reason about:

This is not security as a brake on the product. It is security as the architecture that lets the product operate in places where a free-form model loop would never be trusted.

The competitive advantage is not that OverLift eliminates risk. It is that risk is decomposed into explicit boundaries that can be tested, observed, denied, degraded, recovered, and improved independently.

04 · Threat model

An agentic system expands the attack surface because it connects interpretation to tools, memory, data, and time.

A chatbot can produce a harmful or incorrect answer. An agentic system may also take the answer and use it to select a tool, construct arguments, call an external service, update memory, modify records, message another agent, and continue. Security therefore has to cover the complete workflow—not only the model endpoint.

The useful mindset is adversarial but not theatrical: assume that any text reaching the model may be wrong, any proposal may be stale, any model may be manipulated, any connector may fail, and any optimized path may diverge. Then design the product so those facts reduce capability instead of enlarging authority.

05 · Five boundaries

Privacy, security, authority, safety, and auditability reinforce one another—but they are not interchangeable.

A system may be private but insecure: all work happens locally, yet an injected document can call an unrestricted local tool. A system may be sandboxed but over-authorized: code runs in isolated memory, yet the host exposes a powerful import that can mutate production records. A system may be authorized but unsafe: policy permits an action whose product risk was modeled poorly. A system may be secure in the moment but unauditable afterward.

OverLift treats each boundary as a separate system responsibility so teams can test the actual claim they are making.

06 · Why sandboxing matters—and why it is not enough

A sandbox is a strong room. Authority is the guard, the key ledger, and the rule that decides whether the vault may change.

WebAssembly is valuable because a module has no ambient access to the host environment by default. It can compute inside its own linear memory and interact with the outside world only through functions and resources deliberately supplied by the embedder. In a browser, Workers can further separate ownership, lifecycle, cancellation, and message boundaries from the main document.

Those properties are excellent for exact validators, parsers, compilers, state machines, emulation cores, numerical kernels, and bounded generated or third-party code. They reduce blast radius and make the import surface visible.

But the security of the product depends on what the host exposes.

• A sandboxed module with an imported execute_any_sql function is still overpowered.
• A Worker that receives every customer record has already crossed the privacy boundary.
• A local model that can call a broad application dispatcher still has excessive agency.
• A module hash proves binary identity, not that the business rule inside the module is correct.
• Memory isolation does not authenticate the user or authorize the requested action.
• A timeout limits resource use; it does not decide whether the operation was legitimate.

Containment answers “Where can this code run?” Authority answers “What may this result change?”

The strongest architecture combines both. Sandboxing narrows execution. Capability design narrows reach. Deterministic authority narrows consequence. Receipts make the resulting boundary inspectable.

07 · Prompt injection

Prompt injection is an instruction–data confusion problem. The durable defense is structural.

Direct prompt injection arrives through the user-facing prompt. Indirect prompt injection arrives inside data the application retrieves: a webpage, email, PDF, support ticket, code repository, shared document, memory record, or tool result. The model sees text that may look like an instruction even though the application intended to treat it as evidence.

Filters, delimiters, training, and model-level defenses can reduce risk. They should not be the only thing standing between hostile text and a consequential tool.

OverLift applies a stricter rule:

Retrieved content may influence interpretation. It may not create policy, identity, permission, capability, approval, or official state.

That rule changes the architecture. The application does not ask the model to decide whether a document is allowed to command the system. The document is labeled as content by the surrounding runtime, bound to source identity and provenance, and kept outside the control plane.

A malicious passage can still cause the model to produce a bad proposal. The proposal then meets independent checks:

1. Was the evidence permitted and current?
2. Does the requested capability exist for this principal and target?
3. Do the arguments satisfy a fixed schema and allowlist?
4. Does current policy permit the operation?
5. Has the target state changed since the proposal was formed?
6. Is approval required, valid, unexpired, and bound to the exact action?
7. Would the operation duplicate an existing business result?
8. Can the expected postcondition be verified?

The model may be manipulated. The system must still refuse to convert manipulation into authority.

08 · Capabilities and least privilege

A model can recommend a door. It cannot mint the key.

General-purpose tools make prototypes easy and security review painful. Operations such as execute_sql, fetch_url, write_file, or run_shell expose large, difficult-to-audit power surfaces. Even when a prompt says “use this carefully,” the effective boundary remains broad.

Capability-oriented design replaces ambient access with small, named permissions:

{
  "schema": "overlift.capability-grant@1",
  "capability": "shipment.create-delay-ticket",
  "principalId": "employee-204",
  "tenantId": "meridian",
  "target": {
    "shipmentId": "SHP-1842"
  },
  "allowedArguments": {
    "reasonCode": ["temperature-excursion", "route-closure"]
  },
  "baseRevision": 73,
  "maxCostUsd": 0,
  "deadlineUtc": "2026-08-21T18:30:00Z",
  "requiresApproval": true,
  "revocable": true
}

A capability grant can bind:

• Authenticated principal and delegated identity
• Tenant, account, project, document, shipment, or world scope
• One named operation
• Allowed targets and arguments
• Cost, rate, resource, and concurrency limits
• Deadline and freshness requirements
• Required evidence and approval
• Expected postcondition
• Idempotency and replay policy
• Revocation and lifecycle state

The capability is issued by trusted application logic—not generated by the model and not inferred from natural language alone. The agent may choose among capabilities that the host exposes. It cannot invent a new executable verb.

09 · Deterministic authority

Important actions should cross an independently testable authority plane before execution.

The authority plane converts a broad proposal into a typed verdict. It is the policy decision point, evidence admission boundary, state-transition validator, approval broker, duplicate suppressor, and postcondition contract around consequential work.

AuthorityVerdict Evaluate(ActionProposal proposal, CurrentState state)
{
    RequireAuthenticatedPrincipal(proposal.PrincipalId);
    RequireTenantScope(proposal.TenantId, state.TenantId);
    RequireAdmittedEvidence(proposal.Evidence, state.EvidencePolicy);
    RequireCapability(proposal.Capability, state.CapabilityCatalog);
    RequireCurrentRevision(proposal.BaseRevision, state.Revision);
    RequirePolicy(proposal, state.PolicyVersion);
    RequireNonDuplicate(proposal.IdempotencyKey, proposal.BusinessKey);
    RequireApprovalWhenNeeded(proposal, state.Approvals);
    return AuthorityVerdict.Admit;
}

Real implementations may use a policy engine, a C17/WebAssembly kernel, server-side application code, a state machine, or several cooperating components. The important property is not the language. It is that authority is explicit, replayable, and outside the same probabilistic component that generated the proposal.

Useful verdicts include:

ADMIT
REQUIRE_APPROVAL
CLARIFY
ABSTAIN
DENY
DUPLICATE
STALE
CONFLICT
INVALID
UNVERIFIED

A mature security story includes all of them. A stale action is not the same as an unauthorized action. A duplicate is not a model failure. An unverified outcome is not success. A clarification request is not a refusal. Typed outcomes help the product behave honestly and help operations teams understand what happened.

10 · Browser-based security architecture

The browser can host a meaningful security boundary when responsibilities remain explicit.

Browser-based agentic AI can keep sensitive context close to the user while still using a defense-in-depth architecture:

Browser isolation is not a reason to move every secret or enterprise capability into client code. It is a way to make the private first pass, local evidence, local models, exact kernels, and human approval surface part of one deployable product while keeping shared authority where it belongs.

11 · Product proof

The same security rule appears across very different OverLift products.

The product details differ. The security principle does not: intelligence may explore inside a bounded surface; exact authority decides what the product can trust, expose, execute, and preserve.

12 · Technical treatise

The security boundary is a reference monitor around evidence, capabilities, and state transitions.

Classical security architecture offers a useful mental model: a small, tamper-resistant mediation layer should evaluate every access to a protected resource. Agentic systems expand the protected resources beyond files and APIs. They include evidence eligibility, memory, tool grants, budgets, approvals, revisions, legal transitions, postconditions, and durable records.

Separate policy decision from policy enforcement

A policy decision point evaluates whether the action should be allowed. A policy enforcement point ensures the decision is actually obeyed. In an OverLift-style system, the authority plane may produce a signed or hash-bound verdict, while the tool adapter or WASM Kernel refuses to execute without a valid verdict tied to the same principal, target, arguments, state revision, and deadline.

{
  "schema": "overlift.authority-verdict@1",
  "proposalHash": "sha256:...",
  "verdict": "ADMIT",
  "principalId": "employee-204",
  "capability": "shipment.create-delay-ticket",
  "baseRevision": 73,
  "policyVersion": "shipping-policy-12",
  "approvalId": "approval-991",
  "expiresUtc": "2026-08-21T18:30:00Z",
  "expectedPostcondition": {
    "openTicketCount": 1
  }
}

Bind decisions to state

Security decisions age. A capability that was safe at revision 73 may be unsafe at revision 74. A human may approve a refund before another process issues it. A document may change while a reviewer examines a correction. The system should therefore use optimistic concurrency, target revisions, deadlines, and pre-commit revalidation.

This prevents a time-of-check/time-of-use gap from turning a valid old decision into an invalid new action.

Distinguish request idempotency from business deduplication

Request idempotency asks whether the exact operation key has already executed. Business deduplication asks whether an equivalent outcome already exists. Both matter because a network retry can reuse the same key, while another agent can create a different key for the same business intent.

request key:  action-2026-08-21-000184
business key: shipment:SHP-1842:delay-ticket:temperature-excursion

Treat model output as untrusted structured input

Generated arguments should be parsed into a typed schema, checked for length, range, enum membership, target allowlists, encoding, and contextual safety. Never concatenate generated output into SQL, shell commands, HTML, URLs, or privileged API calls and treat prompt wording as validation.

Protect memory as a security domain

Agent memory can preserve false instructions and cross-session contamination. Useful memory records need identity, tenant, source, provenance, confidence, creation time, expiry, correction, deletion, and purpose. A summary generated by a model should remain distinguishable from the source events it summarizes.

Make supply-chain identity part of replay

Record model route, model version where available, corpus version, policy version, kernel hash, connector version, prompt or instruction version, and critical dependency identity. A receipt that cannot tell which system produced the outcome is not sufficient for a serious incident investigation.

Keep the trusted computing base deliberately small

The larger the set of components allowed to establish identity, grant tools, change policy, commit state, and declare success, the harder the system is to reason about. Models, retrieval systems, and planners should remain replaceable proposal components. The authority plane, exact adapters, state owners, and verification logic should remain smaller, explicit, and heavily tested.

13 · Failure behavior

A secure agentic system should fail by losing capability—not by gaining improvisational freedom.

14 · Honest limits

No single boundary makes an AI system secure.

• WebAssembly reduces ambient access but does not make unsafe host imports safe.
• A Worker isolates ownership and responsiveness but does not automatically isolate sensitive data or authority.
• Prompt filters and model training do not eliminate direct or indirect prompt injection.
• Typed tools can still implement dangerous or incorrect business logic.
• Deterministic authority can enforce a policy that is itself incomplete, biased, or wrong.
• Human approval can be careless, coerced, stale, or applied to a poorly explained action.
• Receipts are only as complete as the evidence, versions, and state the system records.
• Local execution reduces routine disclosure but does not protect data from a compromised browser, device, extension, or origin.
• Cryptographic hashes establish identity and integrity relationships; they do not establish correctness or trustworthiness by themselves.
• Secure deployment, secret management, dependency hygiene, vulnerability response, monitoring, backups, and incident operations remain necessary.
• Some workflows should remain human-only, and some data should never be exposed to an agentic path.
• Security is a lifecycle practice, not a property permanently earned by one successful review.

The goal is not a magical claim. It is a smaller, explicit, testable trusted surface around systems that remain probabilistic, connected, and capable of failure.

15 · Implementation guide

A practical checklist for agentic AI security that survives contact with real tools

1. Name the protected consequences. Identify which outputs can change money, records, access, inventory, safety, legal state, customer communication, or public truth.
2. Draw trust boundaries. Separate users, devices, origins, tenants, providers, Workers, modules, services, connectors, and authoritative stores.
3. Resolve identity outside the prompt. Bind principal, tenant, role, delegation, and scope through authenticated application state.
4. Inventory every capability. List what the agent can read, call, change, persist, message, purchase, or disclose.
5. Replace broad tools. Prefer small named operations over shell, generic SQL, arbitrary URL fetch, unrestricted filesystem, or universal dispatch.
6. Keep credentials server-side where appropriate. The model should not receive reusable secrets simply because it selected a tool.
7. Validate arguments structurally. Enforce schemas, enums, ranges, lengths, target allowlists, encoding, and business rules.
8. Label untrusted content. Preserve source identity, provenance, rights, freshness, and content/instruction separation.
9. Do not rely on prompt filtering alone. Assume a manipulated proposal can reach the authority boundary.
10. Scope memory. Add tenant, user, source, provenance, expiry, correction, deletion, and purpose to durable memory records.
11. Use bounded orchestration. Limit steps, retries, time, tokens, cost, concurrency, storage, and external calls.
12. Define typed proposals. Include target, capability, arguments, evidence, base revision, budget, deadline, risk, approval, and expected postcondition.
13. Create an independent authority verdict. Do not let the same model that proposed the action establish its permission.
14. Bind approval exactly. Record approver, action, target, arguments, evidence digest, policy version, risk, revision, and expiry.
15. Revalidate before commit. Check current state, permission, capability, policy, duplicate state, and approval after any delay.
16. Separate request idempotency from business deduplication. Protect both network retries and equivalent intent.
17. Use exact execution adapters. Translate admitted operations into one bounded connector call or state transition.
18. Verify postconditions. Confirm what changed and what prohibited effects did not occur.
19. Record version identity. Preserve model route, corpus, policy, prompt, connector, runtime, and kernel versions or hashes where available.
20. Seal a receipt. Record evidence, exclusions, verdict, approval, starting state, operation, outcome, postcondition, and replay identity.
21. Design rollback and recovery. Define partial-success handling, reconciliation, checkpoints, compensating action, and human escalation.
22. Test prompt injection as content. Put malicious instructions in webpages, emails, PDFs, tool output, memory, and agent messages.
23. Test denied capabilities. Prove that undeclared tools, targets, methods, hosts, arguments, and tenants remain unreachable.
24. Test stale and concurrent state. Change the target while approval waits and verify the operation cannot commit silently.
25. Test duplicate intent. Use new request keys for equivalent business operations and prove deduplication still works.
26. Test dependency and module failure. Corrupt packs, reject hashes, terminate Workers, lose WebGPU, and fail providers without enlarging authority.
27. Red-team outputs. Attempt HTML injection, unsafe links, SQL, code, command arguments, and misleading success messages.
28. Measure the boundary. Track unauthorized attempts blocked, prompt-injection outcomes, permission failures, duplicate suppression, approval correctness, postcondition success, replay agreement, recovery time, latency, and cost.
29. Review the trusted computing base. Keep the components allowed to grant capabilities, change policy, commit state, and declare success deliberately small.
30. Re-qualify after change. New models, tools, prompts, policies, data sources, connectors, and browser capabilities can change the risk surface.

17 · Why it matters

The future of agentic security should not depend on making models impossible to manipulate.

Models will improve. Prompt-injection defenses will improve. Sandboxes, runtimes, identity systems, policy engines, and browser capabilities will improve. None of that removes the need for a clear architecture around consequence.

A secure product should assume the intelligent component may be mistaken, stale, overconfident, unavailable, or manipulated. It should still know who is acting, which evidence is admissible, which capability exists, which state is current, which approval applies, which action is legal, whether the operation already happened, and what proved the outcome.

Let the sandbox contain execution. Let capabilities limit reach. Let deterministic authority own consequence.

That is the security story the world needs from agentic AI: not “trust the model,” not “trust the prompt,” and not “trust the sandbox.” Trust a system whose important boundaries are explicit, testable, observable, and recoverable.

Explore OverLift Security Architecture Read Deterministic Authority Enter the WASM Kernel