Use cases
Where AISec fits.
Anywhere AI acts on your systems, or on other AI, there is a decision to make and a record to keep.
Enterprises deploying AI agents
Give agents real access, without giving them the keys to everything.
The problem
Agents become useful the moment they can act: file tickets, change records, send emails. Today that often means a shared API key with far more access than the task needs, and no record of why an action was allowed.
How AISec helps
- Each agent gets its own signing identity, so you always know which agent did what.
- Rules are per agent and per action, not per shared key. Anything no rule allows is denied.
- Risky actions can escalate to a human instead of failing or silently succeeding.
- Every decision has a reason your security team can read.
- id: allow-research-payments
description: The research agent may pay vendor invoices and read balances.
effect: allow
caller: research-agent
target: payments-api
actions: [transfer_funds, get_balance] # the AI judge still reviews each call
- id: escalate-ai-transfer-over-1k
description: Transfers above 1,000 initiated by an AI require human approval.
effect: escalate
caller: "kind:ai"
target: payments-api
actions: [transfer_funds]
when:
payload.amount: {gt: 1000}
- id: deny-transfer-over-10k
effect: deny # final: the judge is never asked
target: payments-api
actions: [transfer_funds]
when:
payload.amount: {gt: 10000}MCP tool-call gating
Put a checkpoint in front of every MCP tool.
The problem
The Model Context Protocol makes it easy to connect models to tools: file systems, databases, internal APIs. It also makes it easy for a manipulated prompt to call a tool it should never touch.
How AISec helps
- The AISec MCP proxy sits between MCP clients and servers and checks every tool call. Our demo runs Claude Code through it.
- Allow tools per agent and set conditions on their arguments; everything else is denied by default.
- The AI judge catches tool calls whose intent doesn’t match the user’s request, a common sign of prompt injection.
- Denied calls return a reason the agent can act on, not an opaque error.
- id: allow-copilot-crm-read
effect: allow
caller: [ops-copilot, desktop-assistant]
target: crm-tools-mcp
actions: [lookup_customer, search_tickets]
- id: escalate-external-email
description: Email outside the company domain needs a human (exfiltration risk).
effect: escalate
target: crm-tools-mcp
actions: [send_email]
when:
payload.to: {not_matches: "*@acme.example"}
- id: deny-bulk-customer-export
effect: deny
target: crm-tools-mcp
actions: [export_all_customers]Compliance & audit
Traceability you can hand to an auditor.
The problem
Regulators and customers increasingly ask: what did your AI do, on whose behalf, and why was it allowed? Ordinary application logs are scattered, editable and rarely explain the decision.
How AISec helps
- One record per decision, with caller, target, outcome and reasons.
- Hash-chained into signed blocks and designed to be anchored to a public blockchain, so records can be shown to be unchanged.
- Every policy version is hashed into the ledger, so each decision points to the exact rules that made it.
- Human approvals are signed into the ledger with the reviewer’s name.
- An export built for auditors, who can check the chain without access to your systems.
entry: #1657 · decision · 8335358aa670…
time: 2026-11-03T16:12:05Z
trace: ff36827c… (hop 3 of 4)
caller: research-agent (Ed25519 key dd69873159602ebf, signature valid)
target: payments-api : transfer_funds
outcome: escalate → waiting for human review
policy: aisec-demo-policy @ f6f053949e7b97e4 (loaded in entry #483)
reasons:
- rule: allow-research-payments → allow
- judge: escalate (SP4 scope creep, SP2 vague payment purpose)
proof: Merkle path → signed block, chained to the block before it
anchor: block root anchored on-chainMulti-agent systems
Know where a chain of agents went wrong.
The problem
When agents delegate to agents, a bad outcome can start several hops away from where it shows up. Without a linked trace, finding the hop that went wrong means reading logs from every system involved.
How AISec helps
- Every hop is signed and linked to its parent, forming one trace per request.
- Rules can look at the whole chain: how deep it is, the hop before and who started it.
- Policy caps delegation depth, so runaway chains stop.
- The AI judge checks that each hop still serves the original task, which catches confused-deputy attacks.
- The dashboard shows each hop’s decision and reasons in order.
defaults:
verdict: deny # no matching rule → deny
max_delegation_depth: 3 # AI → AI → AI → system
rules:
- id: escalate-delegated-payments
description: Money moved from inside a delegation chain always needs a human.
effect: escalate
target: payments-api
actions: [transfer_funds]
when:
delegation.depth: {gt: 0}
Policy rules on this page come from our demo setup. The audit record is simplified. Both formats may change during early access.
Put a checkpoint between your AI and everything it touches.
AISec is in early access. Look around the live preview yourself, or book a 30-minute walkthrough with your own use case.
Not ready yet? Join the waitlist.