Ultra13
Platform · Enforcement Model

What is source-to-sink policy for AI agents?

Source-to-sink policy defines which classes of context can influence which actions. For example, a customer ticket may influence a support summary, but it should not authorize a refund, CRM write, data export, or durable memory update without approval. It is the core enforcement model of the Ultra13 Context Firewall.

By the Ultra13 teamPublished Updated
TL;DR
  • A policy maps each source class to the sinks it may influence.
  • Sources carry provenance, trust class, tenant, and freshness.
  • Sinks include tool calls, memory writes, exports, browser actions, and approvals.
  • Decisions are allow, block, redact, quarantine, or require approval — all logged for replay.

How a policy is expressed

Each rule links a source class and condition to an allowed or blocked sink: external customer content can describe a problem but cannot mutate account state; retrieved documents can support an answer but cannot trigger tools; tool results can update observation but cannot expand permissions. See context authority.

Where it runs

The same policy model applies inline, at an LLM proxy, or an MCP gateway — see security architecture, and a worked example in the sample proof report.

FAQ

Frequently asked questions

What is a sink in a source-to-sink policy?
Any action or output context can influence: a tool call, memory write, data export, browser action, code execution, approval, or final answer.

See where the firewall stops the path.

Give us one agent workflow. We’ll map the context boundary, replay the abuse paths, and show where the Context Firewall blocks them.