Exposure filtering
Tenure removes tools outside the active policy before the provider request. The model does not see capabilities it is not allowed to use.
fetch_customerVISIBLEgenerate_emailVISIBLEdelete_customerREMOVED Runtime enforcement Let the model reason.
Let the model reason.
Control what becomes real.
Tenure removes capabilities outside policy before inference, then checks every returned action, argument, and required evidence before it reaches your systems.
The model can propose an action. It cannot grant itself authority.
Two-stage enforcement 01 02
Control both sides of the model call.
An allowlist that only changes the prompt is not an execution boundary. Tenure filters the request before inference and verifies the response before release.
Invocation enforcement
Tenure checks every structured action returned by the provider. Unapproved tools and actions without required evidence are withheld.
generate_emailRELEASEDdelete_customerBLOCKEDsend_emailNO EVIDENCE Identity-bound authority IDENTITYagent:sales-outboundAuthenticated agent token → POLICYsales-outbound:v7Reviewed capability matrix → REQUESTsend_emailArguments and workflow evidence → DECISIONBlock and recordRequired customer state failed
Every agent gets its own boundary.
A Tenure agent token identifies the workload, resolves its active policy, and limits the context and capabilities available on that request.
A valid provider credential proves that a caller can reach a model. It does not prove that this agent should delete a customer, send an email, or export a database.
Required evidence 01 → 02 → 03 Released Blocked Configurable
Allowed does not always mean allowed yet.
A capability may be valid only after an earlier step establishes the state required to use it. Tenure verifies that evidence before releasing the dependent action.
Fetch the customer
fetch_customerThe required prerequisite runs first.
Verify the result
customer_idMATCHactiveTRUEopted_inTRUERelease the action
generate_emailEvery enabled requirement must pass.
Evidence is present
The action remains available to your runtime.
Evidence is missing
The action is withheld before execution.
Your team owns the rule
Observed conditions are suggestions until your team reviews and publishes them.
Per-action decisions
One bad call does not have to erase every valid one.
When a response contains multiple tool calls, Tenure evaluates each call independently. Valid actions can be released while denied actions remain withheld.
MODEL RESPONSE
→ fetch_customergenerate_emaildelete_customerTENURE DECISION
fetch_customerRELEASE
generate_emailRELEASE
delete_customerWITHHOLD
From behavior to boundary 01ObserveCapture exposed and invoked tools. → 02DraftPropose capabilities and evidence. → 03ReviewRemove authority and tune checks. → 04PublishAttach the version to an agent token. → 05EnforceApply the policy on every request.
Build policy from the workflow, not from a blank file.
Auditable decisions Actor Policy Outcome
Know exactly why an action stopped.
Which agent attempted it?
Resolve the agent token, project scope, provider, model, and request.
Which boundary was active?
Record the policy ID and immutable version used for the decision.
What passed or failed?
Inspect tool filtering, capability decisions, precondition results, and final outcome.
Tenure governs requests that pass through it. Direct provider credentials, direct tool execution, and other ungoverned side channels bypass this enforcement boundary.
Control consequences
Put policy between model intent and execution.
Keep the agent framework you already use. Route supported model traffic through Tenure and enforce reviewed authority at runtime.