Semantic Tool Authorization (CASA)
Zero-Trust Authorization for Agent Tool Calls
AI agents decide which tools to call at runtime. That flexibility is also a risk: a prompt injection, a poisoned tool description, or a tampered response can steer an agent into a tool call the user never intended — even when every credential and payment is valid.
AINative's semantic tool authorization verifies every tool call on two axes:
- Structural integrity — is the tool definition, the request, and the response untampered?
- Semantic alignment — does this tool call actually match what the user asked for?
This is our production implementation of CASA (Continuous Agent Semantic Authorization), a zero-trust authorization framework introduced in the research paper Hybrid Inspection and Task-Based Access Control in Zero-Trust Agentic AI (arXiv:2605.02682). CASA is a research framework, not an industry standard — we implement it against real MCP traffic.
Semantic authorization runs in log-only mode by default: it records and surfaces verdicts but never blocks a tool call. A false positive can't break a legitimate workflow. Enterprises opt into soft-block (warn) or hard-block (deny).
The five integrity checks
| Check | What it catches |
|---|---|
| Tool Definition Integrity | Tool poisoning — a server altering a tool's name/description/schema after registration |
| Request Authorization | A tool call the LLM never actually requested |
| Action Alignment | Tool-call swaps — the request says tool A but tool B is invoked |
| Parameter Integrity | Parameter tampering in transit — changed values, added/removed args |
| Data Fidelity | Response falsification — a tool's output altered before the model sees it |
Each is a deterministic SHA-256 / structural comparison. Violations emit a security event you can query and alert on.
Semantic task-tool matching
Beyond structural checks, CASA extracts the user's task from the conversation and classifies each requested tool call against it:
| Relevance | Meaning |
|---|---|
relevant_seed | directly advances the task |
relevant | supports the task |
irrelevant | unrelated to the task |
irrelevant_external | unrelated and touches external/sensitive scope (money, comms, deletion, admin) |
The judgment is tiered for cost: a fast deterministic screen handles every call, and a lightweight model is consulted only on suspicious calls (sensitive-scope tools, or calls with no overlap with the task). Judging runs on AINative's own inference — no third-party API, no surprise cost.
For multi-step agents, chain authorization verifies the whole tool-call sequence aligns with the task, flagging chains that drift off-objective even when each individual call looks plausible.
Security events
Every check emits a structured event to your audit stream:
| Event | Emitted when |
|---|---|
security.tool_integrity_violation | a tool definition no longer matches its registered hash |
security.parameter_integrity_check | requested vs actual call params diverge |
security.data_fidelity_check | a relayed response doesn't match what the tool returned |
security.semantic_authorization | a tool call is scored against the task |
security.chain_authorization | a tool-call chain is scored for drift |
These power detection, alerting, and forensic audit — and, in enforcement mode, the allow/deny decision.
Why it matters
Payment verification (e.g. x402 at the edge) answers "is this agent allowed to spend?" — it does not answer "is this agent doing what the user asked?" Semantic authorization is that second gate. Together they form a double barrier: a paid request is still stopped if it doesn't match intent.
This maps directly to enterprise security review and SOC 2 — a concrete, event-logged answer to "how do you stop an agent doing something it wasn't authorized to?"
Status
Semantic authorization is live in log-only mode — producing verdicts and audit events on tool calls. Enforcement (soft/hard-block) is available as an enterprise opt-in. Contact us to enable blocking for your organization.