Proposal is not execution
A model seeing or proposing a tool does not mean the business effect should be authorized.
Preventive control · Intercepted actions
Control the action before it becomes a business effect.
A safe model response is not enough if the next step is a refund, publish, delete, export or production change. Talon governs the action paths it can actually intercept: decide before upstream execution, keep the exact boundary explicit, and leave verifiable evidence behind the decision.
AI proposes: create_refund_request
amount: EUR 50.00
intercepted action
→ trusted action definition
→ exact normalized payload
→ policy decision
DENY
→ zero upstream execution
→ signed denial
REQUIRE_APPROVAL [HTTP Action Gateway today]
→ exact operation + reviewer authorization
→ approval itself performs no dispatch
→ revalidate → one execution attempt
→ signed lifecycle outcomeTool filteringMCP interceptionExact action bindingALLOW · DENY · REQUIRE_APPROVALOne-use authorizationSigned lifecycle evidence
Why the boundary matters
The model request is often not the consequential event.
Agents increasingly turn model output into actions. A gateway that only observes prompts and responses can miss the moment where a business effect becomes real. Talon’s design center is the boundary it can intercept before that effect is dispatched.
Approval must bind the exact effect
“Approve refunds” is too broad. The useful subject is the exact operation, material payload and destination.
Unknown is a real outcome
If dispatch may have happened but the result is lost, a control plane must not blindly retry and duplicate the effect.
Available now
Talon already governs intercepted tool paths.
Tool schemas visible in LLM requests can be filtered or blocked. MCP tools/call routed through Talon can be intercepted and denied before upstream execution, with signed denial evidence. Data, provider and destination policy remain part of the same control boundary.
Boundary: local shell commands, file edits, browser actions and direct APIs that bypass Talon remain invisible and uncontrolled.
through Talon
→ visible to policy
→ allow / deny / filter
→ signed evidence
bypasses Talon
→ no interception
→ no Talon control
→ no completeness claimShipped on the HTTP Action Gateway · broader convergence in progress
Authorize this exact action, not just a tool name.
The public HTTP Action Gateway ships trusted catalogued action definitions, schema-validated arguments, immutable operation binding, DENY > REQUIRE_APPROVAL > ALLOW, tenant-scoped approver decisions, runtime-only dispatch claims, at-most-once Talon-forwarded HTTP dispatch and signed lifecycle evidence. An ambiguous post-dispatch outcome remains unknown; Talon does not blindly retry.
Still in progress: MCP tools/call, native tool execution and Plan Review do not yet use this exact-action spine. Trusted MCP sources can populate the catalogue, but MCP-sourced actions cannot yet dispatch via the HTTP Action Gateway. Talon owns authorization, not the external runtime's waiting or workflow orchestration.
operation_id
+ action identity
+ material payload digest
+ destination
+ policy generation
DENY > REQUIRE_APPROVAL > ALLOW
approval decision
≠ dispatch
possible dispatch + unknown result
→ UNKNOWN
→ no blind retryOne buyer proof
Prove the shipped HTTP authorization boundary.
| Step | What the HTTP Action Gateway can prove |
|---|---|
| AI attempts one consequential action | One exact authorization subject is established from trusted action metadata and the final material arguments. |
| Policy requires approval | Downstream call count remains zero. |
| Authorized reviewer approves | The decision records authorization but still performs zero dispatch. |
| Runtime resumes | The runtime claims an attempt; Talon revalidates the bound action and current policy before at-most-once HTTP dispatch. Approval itself never dispatches. |
| Outcome is known or unknown | Known success/failure is recorded; ambiguous post-dispatch state is conservative and never blind-retried. |
| Evidence is verified | Policy, approval, attempt and outcome form one signed lifecycle that can be checked later. |
What Talon is not
Not an MCP gateway company. Not a workflow engine. Not endpoint security.
MCP is one standards-native transport beneath the control plane. External orchestrators keep workflow and waiting responsibility. Talon focuses on deterministic company policy, exact intercepted-action authorization and proof—not on owning every connector or every local effect.
Talon owns:
policy boundary
action authorization
operation identity
approval binding
evidence
runtime / orchestrator owns:
agent loop
workflow waiting
local execution outside Talon
business application logicStart with one consequential action
Pick the effect your company policy must authorize before it happens.
Use a refund, production change, database mutation, delete, export or external communication as the test. Make the decision happen at the real interception boundary, prove zero dispatch on denial, and keep the authorization evidence.