Secure Every Action
AvailableThe model requests.Authorization decides.
Trustivan runs an authorization gate outside the model. An agent runtime asks before it acts; the acting principal is resolved from the credential it presented rather than claimed in the request; thirteen rules evaluate credential state, tool entitlement, effect, resource impact, declared autonomy, standing grants, source address and hour; and the strictest verdict — ALLOW, CHALLENGE or DENY — comes back naming the rule that produced it.
cleanup-bot → s3:DeleteBucket prod-backupsThe model can request an action. The authorization system decides.- Action requests3:DeleteBucket
- Principalfrom the credentialnot from the request
- Credentiallive · unexpired
- Tool entitlementdeclared by operator
- Effectmutating
- Resourcehigh impact
- Autonomyautonomous
- Standing grantnone active
- ALLOW
- CHALLENGE
- DENY
mutating_action_on_high_impact_resource and no_active_grant_for_elevated_action. Both route the action to a person. The strictest verdict wins, the rules that fired are named on the decision, and the record cannot be edited afterwards.Problem
Guardrails filter text. They do not authorize actions.
An agent with a valid credential and an injected instruction passes every prompt filter and still deletes the bucket. The decision must be made where the prompt cannot reach.
Permission Is Not Authority
A role that allows delete says nothing about whether this agent should delete this bucket at 02:00 for this ticket
The Prompt Is Attack Surface
Anything the model reads can rewrite what it asks for, so the model’s own judgement cannot be the control
Speed Removes the Pause
Agents chain tools in milliseconds; the human review that sat between intent and action is gone unless something puts it back
Model
Thirteen rules. Three verdicts.
Principal → credential → tool entitlement → effect → resource impact → autonomy → standing grant → source address and hour → decision. Each rule returns its own verdict and the strictest one wins, so a rule can refuse an action but never widen access.
ALLOW
No rule objected. The runtime proceeds, and the decision is recorded either way.
CHALLENGE
The action needs a human before it should proceed. The runtime stops and escalates. Depending on the rule, an access grant approved by someone other than the requester, or an operator declaration, is what turns a later attempt into ALLOW.
DENY
A rule refused, or no rule spoke at all. The runtime does not act. Deny-by-default: an empty rule set denies rather than permits.
Scenarios
Same evaluation. Different answers.
How impact, effect and entitlement change the outcome for five everyday agent actions.
| Requested action | Impact | Effect | Context | Decision |
|---|---|---|---|---|
Read a ticketsupport-agent → tickets:read OPS-4821 | Low | Read | Tool entitled to the agent; credential live; read-only effect | ALLOWNo rule objected |
Open a pull requestdocs-agent → github.pulls:create platform/docs | Moderate | Write | Entitled write to a discovered repository not classified high impact; supervised autonomy | ALLOWRecorded either way, with the rules that ran |
Rotate a keyrotation-agent → secrets:rotate prod/payments | High | Write | Mutating action on a high-impact resource; no grant standing behind it | CHALLENGEA grant, approved by someone else, turns the retry into ALLOW |
Delete prod bucketcleanup-bot → s3:DeleteBucket prod-backups | Critical | Administrative | Unsupervised autonomy; administrative action on a high-impact resource; no grant | CHALLENGEA person decides; a grant approved by someone else is the way through |
Call an undiscovered toolresearch-agent → mcp://unlisted/exec | Unknown | Unknown | The tool was never discovered, and no entitlement names it | DENYtool_not_entitled refused it, and the record names the rule |
How it works
Resistant to injection. Honest about impact. Recorded every time.
Three properties the gate is built around. Each is implemented; what an operator must declare for it to apply is stated with it.
Injection changes the request. It cannot change the authority.Available
Authorization reads the principal, credential, tool entitlement, effect, resource impact, autonomy and grants from the control plane — none of which the model can alter by reading a hostile web page. Whatever the prompt says, the decision is made from facts the prompt does not control.
- The acting principal comes from the presented credential, never from the request body — an agent claiming to be another agent is not expressible in this API.
- Deny by default: an empty rule set denies. A rule returning allow is only declining to object; it can never widen access.
- The runtime gets a reason it can report, and the decision record names the rule that produced it.
- Support ticket bodycustomer-written
- Fetched web pagecontains hidden instruction
- Forwarded emailuntrusted sender
export customer_360 → https://ext.example/uploadShaped by the injected instruction- Principalsupport-agent · resolved from the presented credential
- Credentiallive · not revoked · expires in 41 d
- Entitlementdata-export · not entitled to support-agent
- Effectwrite · publisher did not mark it read-only
- Resourcecustomer_360 · impact: high
High-impact actions get a human in the loop — with the evidenceAvailable
A mutating action against a high-impact resource, or an elevated action with no standing grant behind it, does not simply fail. The gate returns CHALLENGE, and an access grant — requested, approved by someone other than the requester, and bounded to at most seven days — is what turns the next attempt into ALLOW.
- Resource impact drives the rule, not the name of the tool — an operator classifies the resource, and an unclassified one is not silently treated as harmless.
- Grants are scoped and time-bounded: one target, one window, seven days at the outside, and nobody approves their own request — refused in the domain, the repository and a database trigger.
- A lapsed grant stops authorizing at read time, though no scheduler writes the expiry event yet.
- 14:02:11The agent runtime asks before it acts
rotation-agent → secrets:rotate prod/payments · the acting principal is read from the presented credential, not from the request
- 14:02:11The gate evaluates and returns the strictest verdictCHALLENGE
Mutating effect · high-impact resource · no grant standing behind the action
- 14:02:12The runtime stops and an access grant is requested
The request names one agent, one target and one window; the decision record already holds the rule that fired
- 14:09:47Approved by someone other than the requesterGRANT ACTIVE
Self-approval is refused in the domain, the repository and a database trigger. The grant is time-bounded — seven days at the outside
- 14:09:49The next attempt is allowed, and recordedEVIDENCE ATTACHED
The same action now finds a live grant and returns ALLOW; both decision records are immutable
Every decision leaves a recordAvailable
A decision is only defensible if it can be reconstructed later: which principal asked, what it asked for, which rules fired and on whose declaration the entitlement rested. Trustivan records that for every evaluated action, and the record is immutable — enforced by a database trigger rather than by convention, with secret-shaped text refused in the evidence a decision carries.
Why was this allowed — and would it be allowed again tomorrow?
Explore agent provenanceAgent attempted an administrative action on production data with no grant
- Decision
- CHALLENGE
- Principal
- cleanup-bot · resolved from the presented credential, not the request
- Credential
- live · issued 12 d ago · expires in 78 d · not revoked
- Action
- s3:DeleteBucket
- Tool entitlement
- aws.s3 · entitled · source: operator declaration
- Effect
- administrative · basis: operator declared
- Resource
- s3://prod-backups · impact: high
- Autonomy
- unsupervised · basis: operator declared
- Standing grant
- none active for this target — a grant approved by someone else turns a retry into ALLOW
- Rules fired
- mutating_action_on_high_impact_resource · unsupervised_mutating_action · no_active_grant_for_elevated_action
- Recorded intent
- ticket OPS-4821 — kept for the investigator; no rule reads it
Scope
What this is not
Three useful categories Trustivan complements — and deliberately does not try to replace.
Not an AI firewall
Filtering prompts and model output is worthwhile; it still cannot say whether the resulting action should be authorized
Not an MCP gateway
Proxying tool traffic shows you the calls; authorization needs the identity, credential, entitlement and resource impact behind each one
Not the LLM’s own guardrails
System prompts and refusal training are part of the attack surface; the security boundary has to sit outside the model
What is built, and what an operator has to supply
The runtime gate is built: an agent runtime presents its credential, thirteen deny-by-default rules decide with the strictest verdict winning, and the decision is recorded immutably. It enforces only where the runtime calls it, and it does not find the estate it governs: no connector discovers an agent and no screen registers one, so outside a synthetic demo seeder the agent inventory is empty. The observed half of tool entitlement is permanently unavailable, so entitlements are operator declarations and every decision names which source it read. Intent is recorded for the investigator and read by no rule — a stated purpose is what an attacker forges. Replay protection is opt-in: a repeated requestId is answered with the recorded decision. No scheduler writes grant expiry.
See the full platform trajectorySee the decision on a sample action.
A demo walks through a synthetic seeded agent, its declared tool entitlements and a high-impact action evaluated outside the model — with the decision record it leaves behind.