How it works

What actually happens between a request and a result.

Every request enters Tenure through an authenticated token. Tenure resolves the precise context lanes that token is allowed to inherit, strips forbidden capabilities before the model ever encounters them, and traps unsafe tool calls before they can execute against your business systems.

The request path

One request. A series of deterministic checkpoints.

Tenure sits on the model request path, outside the agent loop. Frameworks iterate. Models shift. The out-of-model policy boundary remains absolute.

01 Authenticate Identify the Tenure token and the policy attached to it.
02 Resolve context Load the scoped context lanes and structured beliefs.
03 Project capabilities Remove capability definitions the active policy does not allow.
04 Call the model Forward the constrained request using the supported provider protocol.
05 Authorize invocation Release or block structured calls before they reach your runtime.
Scoped beliefs

Context is resolved before inference.

Tenure injects precise structured beliefs instead of flattening loose conversation history into one retrieval pool. Organizational rules, team practices, project context, and user preferences remain scoped instead of being flattened into one retrieval pool.

Observation

Behavior is captured without becoming policy.

Observe mode records what capabilities were supplied, what the model could see, what it invoked, which providers and models appeared, and how that behavior changes over time.

Audit

Enforcement decisions become durable evidence.

Once policy is active, Tenure records the policy version applied and the decisions it made, including capability filtering, release, block, and request denial.

Two sides of enforcement

Policy controls what the model can see and what can reach your runtime.

A request can offer more capability than policy permits without making the entire request invalid. Tenure narrows the model's effective capability surface before inference, then checks returned invocations again on the way back.

SUPPLIED BY APPLICATION
fetch_customer_profileKEEP
send_emailKEEP
jira.create_issueREMOVE
confluence.searchREMOVE
POLICY
EXPOSED TO MODEL
fetch_customer_profileVISIBLE
send_emailVISIBLE
jira.create_issueHIDDEN
confluence.searchHIDDEN
MODEL
RETURNED INVOCATION
send_emailRELEASE
jira.create_issueBLOCK
Exposure filtering

Before inference, Tenure removes capability definitions the active policy does not allow. The model never sees them. The request can continue with the capability surface policy actually permits.

Invocation enforcement

After inference, Tenure normalizes every structured invocation and checks it against policy again. Disallowed calls are withheld before they reach the application runtime.

Forced capability denial

If the caller explicitly requires a specific disallowed capability, or filtering makes an explicit request constraint impossible to satisfy, Tenure rejects the request instead of silently changing its meaning.

From observation to enforcement

You do not have to write the policy first.

Tenure can observe how an agent is actually configured and used, collapse that activity into a reviewable behavioral profile, and turn the reviewed result into an enforceable policy.

STEP 1 Observe Capabilities, models, providers, usage
STEP 2 Draft Aggregate behavior into a policy candidate
STEP 3 Review Invoked capabilities selected by default
STEP 4 Publish Attach the reviewed policy to the token
STEP 5 Enforce Apply it on every request
OBSERVED EXPOSURE

What was available?

The capabilities the application supplied and the subset Tenure exposed to the model. This is the agent's potential surface, not proof that every capability is needed.

OBSERVED USE

What was actually invoked?

Capabilities the model returned as structured calls, with invocation counts and first and last seen dates drawn from the observation window.

What Tenure learns about an agent

A behavioral profile, not a pile of request logs.

The Agents view collapses high-volume observations into the signals needed to understand behavior and draft policy, while still keeping recent raw observations available for investigation.

CAPABILITIES

Available versus invoked

See every capability observed as available to the model, which ones the model actually invoked, and which remained unused.

FREQUENCY

Counts and recency

Invocation counts plus first and last seen dates make low-frequency but legitimate capabilities visible without relying on only the latest requests.

ROUTING

Providers and models

Track which providers and models appear on the token so routing behavior is visible alongside capability behavior.

USAGE

Token consumption

Record per-request token usage and roll it up over time by agent, provider, and model for cost visibility and future consumption controls.

The agent detail view keeps the most recent observations available for drill-down, while policy drafting works from the aggregated capability profile rather than assuming the latest 100 requests represent the agent's full behavior.

Three records, three jobs

Observing agent behavior, enforcing governance, and accounting for token costs are entirely different engineering challenges.

Tenure keeps these concerns separate so high-volume behavioral logging does not have to serve as permanent audit evidence or long-term usage accounting.

Observations

The behavioral evidence

What was supplied, exposed, and invoked; invocation arguments and call IDs; provider and model activity; counts and first or last seen dates. Granular, high volume, and time limited.

What shape does this agent's behavior have?
Usage

The consumption record

Per-request token counts linked to the same request or observation when available, with independent retention and aggregation by agent, model, provider, and time window.

How much model capacity did this agent consume?
The capability lifecycle

Four states define Tenure's enforcement boundary.

The wire format differs by provider protocol, but Tenure reduces the lifecycle to the same small set of states before policy is evaluated.

STAGE 1 Supplied Application includes it
STAGE 2 Exposed Tenure forwards it to the model
STAGE 3 Invoked Model emits a structured call
STAGE 4 Tenure decision Release or block
RELEASED

Allowed back to your runtime

The invocation is returned to your application runtime. What happens after that point belongs to your infrastructure, not to Tenure.

BLOCKED

Withheld before release

Policy says no. Tenure withholds the structured invocation and records the attempted call and enforcement decision.

REJECTED

Explicit constraint cannot be satisfied

When the caller explicitly requires a disallowed capability, Tenure rejects the request rather than silently altering what the caller asked the model to do.

Tenure's authority ends at release. It does not claim to know whether a released action succeeded, failed, was ignored, or produced a side effect after it reached the application runtime.

Protocol-level, not framework-level

Govern the model request path without coupling policy to an agent SDK.

Tenure normalizes each supported ingress protocol into the same internal capability identities. Policy evaluation does not need to know which agent framework constructed the request or which provider-specific field carried the tool definition.

Custom agent Agent framework Application code AI client
SUPPORTED INGRESS OpenAI / Anthropic protocols Normalize supplied capabilities and returned invocations
TENURE CORE Canonical policy evaluation Filter, authorize, audit

Protocol adapters understand provider wire formats. The enforcement core operates on canonical identities. Observation and enforcement share the same normalization logic, but runtime decisions never depend on querying historical observations.

The full picture

Five critical governance questions and the layers that answer them

What context should this caller receive? Scoped beliefs
What capabilities did the application offer? Observation
What capabilities does the agent demonstrate it needs? Observed invocation
What should the agent be allowed to do? Reviewed policy
What did Tenure actually permit or prevent? Audit

Scoped beliefs supplies the right context. Observation builds the evidence. Policy turns evidence into a reviewed decision. Enforcement applies that decision on the request path. Audit proves what Tenure did.

Get started

Put Tenure on the request path.

Run Tenure locally, observe an agent's real capability surface, generate a policy draft, and enforce the reviewed policy without changing how the agent reasons.

Self-hosted · No call-home telemetry