An agent receives a private spreadsheet and is asked to explain why revenue changed between two months. It calls a model to write an analysis, runs generated code to calculate the numbers, and returns a confident paragraph with a chart. The user now needs to know more than whether the paragraph sounds good.
Which model ran? Could the service operator, the party responsible for running the service, read the spreadsheet? Did the generated code run under a network and filesystem policy? Can someone reproduce the calculation? Did the result pass a test that was written for this task?
Those questions describe two different AI services. An inference service runs a model on an input and returns model output. A sandbox execution service runs customer-supplied or model-generated code inside a restricted environment. They can be composed into one agent workflow, but they should not share one vague “verified” label.
Tangle is a coordination network for services that independent parties run. Its contracts record selected registration, service, payment, verification, and lifecycle state while application work runs outside the chain. Off-chain means computed outside the blockchain, while on-chain means recorded in blockchain state. Tangle records the service contract and lifecycle state, while operators perform inference and sandbox execution off-chain and return evidence through the Job result. A Blueprint is a reusable service template that defines jobs, artifacts, metadata, and optional protocol rules. An operator is the party that runs the Blueprint and executes its jobs. A Service is one configured instance with an owner, operator set, payment terms, and lifecycle state. A Job is one callable unit of work inside the Service. The Blueprint Manager is the operator-facing process that keeps the running service aligned with protocol state. The Blueprint Runner receives job calls, routes them to handlers, and returns results. The Tangle Blueprint documentation defines those objects.
The goal is a claim a customer can inspect: what ran, which policy applied, what evidence came back, and what the evidence still does not prove.
Separate inference from sandbox execution
The agent profile is the versioned bundle of model choice, instructions, tools, permissions, resource limits, and output schema that guides the workflow. The runtime is the process and environment that carries out that profile. A trusted execution environment, or TEE, is a hardware-backed area that isolates a workload from ordinary host software. An attestation report is signed evidence about that environment and the measurements of the code or configuration that started there. A task evaluation is a repeatable test or judging procedure for the property a customer cares about. A trace is a time-ordered record of the execution path. An accounting invariant is a condition that must remain true, such as a total equaling the sum of its line items.
For the spreadsheet example, the profile might say:
1. Read the user’s spreadsheet.
2. Ask an inference service for a proposed analysis plan.
3. Run only the proposed code in a sandbox with no outbound network.
4. Check the result against accounting invariants.
5. Return the code, result, evidence, and an uncertainty note.The model call and the code run create different risks.
| Stage | What the customer sends | Primary risk | Evidence that fits |
|---|---|---|---|
| Inference | Prompt, files, model options, or structured data | The wrong model ran, the input was exposed, or the output changed | Model identity, execution policy, attestation where required, and task evaluation |
| Sandbox | Code, input files, and resource policy | Code escaped into the host, or the operator changed the run | Isolation policy, artifact identity, resource record, trace, and output check |
The separation prevents a familiar category error. A TEE can provide evidence about a protected workload. It does not prove a model’s answer is helpful. A sandbox can restrict network access. It does not prove the generated program calculated the intended metric.
Inference needs identity and quality checks
An inference job should make four claims separately:
- The declared model or model family was selected.
- The input reached the intended execution boundary.
- The service returned the model output or a clearly marked transformation of it.
- The output meets the task’s quality rule.
A model fingerprint is a cryptographic summary of the model files or image that the service says it loaded. When the model identity is included in the measured claim, a client can compare the attestation report with the approved model or container identity before releasing a secret.
The TEE article in this series explains why that check is narrower than “the answer is correct.” The Amazon Web Services (AWS) Nitro attestation guide shows one public provider flow in which an external service compares signed measurements with an access policy. The Blueprint lifecycle guide shows where that inference Job sits in the larger operator and Service path.
An inference response can expose evidence such as:
| Field | What it supports | What it does not support |
|---|---|---|
| Model identifier or digest | Which model release the service intended to use | That the model follows instructions |
| Attestation report | Which protected workload produced the report | That the provider’s entire system is private |
| Usage data | The tokens or resources the service reports consuming | That the usage is independently measured |
| Output | The text or structured result returned | That the answer is factually correct |
| Evaluation result | Whether selected tests passed | That unseen inputs will pass |
The client should reject ambiguous evidence. If a model identifier is only a display name, call it a name rather than a cryptographic identity. If the report has not been verified, call it an unverified report rather than attestation proof. If no quality check ran, return “not evaluated” rather than a green status.
Sandbox execution needs a written policy
A sandbox is a restricted execution environment for untrusted or model-generated code. The word “sandbox” is incomplete until the policy states what the process may access.
For the spreadsheet job, a reasonable first policy might be:
| Policy area | Example decision |
|---|---|
| Processor and memory | 2 processor cores, 1 GiB memory, 30-second wall-clock limit |
| Network | No outbound network and no inbound listeners |
| Filesystem | Read-only input directory and temporary output directory |
| Processes | No child process creation and no privileged system calls |
| Dependencies | Only packages included in the approved image |
| Lifetime | Destroy the environment after the result is collected |
| Output | Return selected files and standard output, redact secrets |
| Records | Keep policy version, exit state, resource usage, and output hash |
The values in this table are an illustrative policy, not a Tangle default. The operator and customer must choose limits that match the language, data, and workload.
Isolation must hold across runs as well as within one run. If a process, file, environment variable, or cache survives into the next customer’s job, the service has a cross-tenant data problem. If the sandbox allows unrestricted network access, generated code can send the spreadsheet elsewhere even when the host cannot read the sandbox memory.
A trace makes the execution inspectable
The trace for the sandbox is the time-ordered record of what happened during a run. For the sandbox, it can include:
job_call_id: 17
artifact_digest: sha256:approved-image
policy_version: spreadsheet-sandbox-v2
input_fingerprint: sha256:input
started_at: 2026-08-03T15:00:00Z
network: denied
peak_memory: recorded by operator runtime
exit_status: 0
output_fingerprint: sha256:result
evaluation: accounting-invariants / passedThe values in the trace are illustrative. The important fields are the links between the Job, artifact, policy, input, output, and evaluation.
A trace is evidence about an execution path. It is not automatically independent evidence because the operator may write it. Protect selected fields with signatures, attestation, protocol events, or a reproducible check when the customer needs stronger provenance.
For the spreadsheet, it might assert that monthly totals equal the sum of line items, that percentages stay within a valid range, and that the generated code includes the source columns it used. The evaluation should be versioned alongside the service and report which cases it covered.
A job router connects public jobs to private handlers
A job router is the traffic director inside the Blueprint Runner. It maps a job identifier to the handler that should execute it. The current Tangle router reference shows the minimal Blueprint software development kit (SDK) shape:
use blueprint_sdk::Router;
let router = Router::new()
.route(MY_JOB_ID, my_job)
.with_context(my_context);For an AI Blueprint, the routes might represent infer, run_sandbox, and get_result.
The placeholders in the snippet are from the public documentation and are not a complete inference implementation.
The job router can make the job boundary explicit and reject unknown IDs. It does not decide whether the model output is accurate or whether the sandbox policy was strong enough. Those checks belong to the handler, runner, manager, evaluation, and protocol configuration around the route.
Payment can be machine-readable without proving the work
x402 is an open protocol for programmatic payment over the Hypertext Transfer Protocol (HTTP).
The client makes a request.
The server returns HTTP 402 Payment Required with payment requirements.
The client signs a payment payload and retries with the payment header.
The server or a facilitator verifies and settles the payment before serving or enqueuing the resource.
The official x402 flow documents PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE headers.
Tangle exposes x402 as an optional, operator-run HTTP gateway for paid job execution.
A facilitator is the service that verifies and settles an x402 payment for the gateway.
A JobCall is the internal message that carries an accepted paid request into the Blueprint Runner.
The Tangle x402 documentation says that the gateway verifies and settles payment through a facilitator and then injects a JobCall into the Blueprint Runner.
The gateway’s current endpoint shape is:
GET /x402/health
GET /x402/jobs/{service_id}/{job_index}/price
POST /x402/jobs/{service_id}/{job_index}The paid POST returns 402 when payment is missing or invalid.
After a valid payment settles, it returns 202 Accepted when the request is enqueued.
202 means the service accepted the work; it does not mean inference or sandbox execution has completed.
The current restricted-policy example opts in per job:
default_invocation_mode = "disabled"
[[job_policies]]
service_id = 1
job_index = 0
invocation_mode = "public_paid"
[[job_policies]]
service_id = 1
job_index = 1
invocation_mode = "restricted_paid"
auth_mode = "payer_is_caller"
tangle_rpc_url = "https://rpc.tangle.tools"
tangle_contract = "0xYourTangleContract"The values are taken from the public documentation as a configuration shape. Use the target release’s current field names and contract address. The default-disabled policy is a good boundary because a new Job is not accidentally exposed for paid public calls.
Payment and execution should remain separate in the trace:
request -> 402 payment requirements -> signed payment -> settlement
|
v
JobCall accepted and queued
|
inference or sandbox runtime executes
|
result + evidence + evaluationAn agent should not stop after payment. It should wait for a completion state, retrieve the result, inspect the evidence, and apply its own acceptance policy.
Combining inference and sandbox execution
Return to the spreadsheet assistant. The workflow can be implemented as two Tangle Jobs in one Blueprint or as two Services with different operator and confidentiality policies.
Step one: ask the model for a plan
The inference Job receives a schema describing the available columns and asks the model to produce a plan and code. The service returns both the proposed code and a structured explanation of the inputs it used.
The customer can then inspect the code before it runs. An automatic evaluator can reject code that imports network libraries, reads outside the input directory, or writes files outside the output directory.
Step two: run the code under a policy
The sandbox Job receives the approved code, the spreadsheet, and the sandbox policy. The runtime starts from a clean environment, denies the network, applies resource limits, and returns the output plus a trace.
Step three: check the result
The evaluation checks accounting invariants and compares selected values with a reference calculation. If the code produces a plausible chart but violates an invariant, the service returns a failed evaluation rather than a successful answer.
Step four: expose the evidence
The response should distinguish model output, generated code, sandbox output, and evaluation state. One useful response shape is:
{
"status": "completed",
"analysis": {
"explanation": "Revenue fell because the enterprise segment ...",
"code": "<generated code>",
"result": { "enterprise_change": -0.12 }
},
"evidence": {
"inference": { "model": "approved-model-digest", "attestation": "verified" },
"sandbox": { "policy": "spreadsheet-sandbox-v2", "network": "denied", "exit_code": 0 },
"evaluation": { "name": "accounting-invariants-v1", "status": "passed" },
"trace_id": "trace-17"
}
}This is an illustrative response shape. It demonstrates the boundary the public interface should expose; it does not claim that the current Tangle gateway returns these exact fields.
The analysis field is generated output.
The evidence fields should link to records the client can check.
If an application adopts this shape, it should keep status as review_required when a check is missing or ambiguous.
Failure modes for inference and sandbox execution
Model substitution
An operator advertises an expensive model and runs a cheaper one. Model identity evidence, attestation, model fingerprints, canaries, and task evaluations can detect selected forms of substitution. No one canary covers every prompt.
Prompt or input exposure
The model host logs prompts or stores uploaded files. A TEE policy can protect the workload from the ordinary host during execution, but the application still needs output, logging, and retention controls. If the client sends data before validating attestation, the later report cannot repair the disclosure.
Generated code escapes
The code opens a socket, reads a host path, or starts a privileged process. The sandbox must deny those operations and test the denial path with adversarial programs. “The process exited successfully” is not evidence that the policy held.
The code returns the wrong number
Isolation can be perfect while the code calculates the wrong metric. The evaluation must test the business rule with labeled inputs or reference computations.
Operators disagree
The inference output may be non-deterministic. The sandbox may use time, randomness, floating-point libraries, or a dependency that changed between images. Define normalization, tolerances, and the dispute state before comparing results.
The paid request is accepted but never completes
The x402 gateway may return 202 after enqueueing.
The operator can be offline, the job can time out, or the Service can expire.
The caller needs a timeout, status endpoint, retry policy, and a way to distinguish an accepted payment from completed work.
A trace is incomplete
If a field is missing, record it as unknown. Do not turn an absent network record or resource metric into a false zero. The customer should know which evidence the operator could not capture.
Pick the first service from the risk
Build inference first when the main customer question is “which model ran, and what did it return?” Publish the model identity, input policy, output shape, evaluation, and evidence boundary.
Build a sandbox first when the main question is “can this code run under a policy without escaping?” Publish the filesystem, network, process, resource, lifetime, and output rules.
Combine them when generated code must operate on private data and the customer needs evidence from both stages. Keep the inference and sandbox claims separate even when one Blueprint owns both Jobs.
Use a conventional hosted service when inputs are public, the workflow is low risk, latency is the main constraint, and operator evidence would not change the customer’s decision. Tangle becomes useful when independent operators, explicit execution policy, machine payment, or inspectable result handling changes the customer’s decision.
Start with one model, one language, one policy, one evaluation, and one failure path. The minimum useful deployment contains one model, one execution policy, one trace, one evaluation rule, and one result endpoint. Those records let a customer answer what ran, where it ran, what it touched, and why the result was accepted.
What is AI agent infrastructure?
It is the software around an agent’s model and tools: the runtime, service calls, data and code boundaries, payment path, traces, evaluations, and recovery behavior that make a workflow usable outside a one-off prompt.
What is the difference between inference and sandbox execution?
Inference runs a model and returns model output. Sandbox execution runs code under a resource and access policy. The first centers on model identity and output quality. The second centers on isolation, resource limits, and the behavior of the code that ran.
Does a TEE prove that an inference result is correct?
No. TEE attestation can provide evidence about the protected environment and measured workload. Correctness and usefulness need a separate evaluation or proof.
Can a sandbox run arbitrary code safely?
Only within a defined and tested policy. The service must specify network, filesystem, process, resource, lifetime, and output rules, then test escape attempts and malformed inputs.
What does a trace prove?
A trace records the execution path and makes failures easier to inspect. Its trust depends on how each field is produced and protected. Use attestation, signatures, protocol events, or reproducible checks when the trace must support a stronger claim.
What does x402 payment evidence show?
x402 payment evidence shows that a payment request followed the configured payment verification and settlement flow. It does not prove that the paid Job completed correctly or that the output passed an evaluation.
Why use more than one operator?
Running the same deterministic or normalized Job across independent operators can improve availability and expose disagreement between operator-attributed results. They do not guarantee correctness when operators share artifacts, dependencies, infrastructure, or a faulty task specification.
Public sources
The Tangle Blueprint documentation defines Blueprints, Services, Jobs, operators, and triggers.
The Tangle x402 gateway guide documents payment-gated job endpoints, policy modes, and 202 Accepted enqueue semantics.
The Tangle execution confidentiality guide documents TEE policy values and source selection.
The Tangle Runner router reference documents job dispatch.
The Coinbase x402 documentation documents the payment protocol and header flow.
The Blueprint SDK repository is the source for current examples and release behavior.
Inference and sandbox execution become trustworthy at different boundaries. The service is ready to expose when those boundaries are explicit, the smallest public example works, and every missing or failed check remains visible to the caller.