AI Security by Design

Every AI request: verified, decided and on the record.

AISec sits between your AI agents, your systems and each other. At every hop it checks who’s calling and applies your policy, then explains the decision and records it in a ledger you can prove hasn’t been rewritten.

Signed request agent:planner → tool:crm.read
  1. Identity Ed25519 signature verified, nonce checked against replay
  2. Policy Deterministic rules: caller, scope, rate, delegation depth
  3. AI judge Checks intent against your written policy. Can only tighten.
  4. Ledger Decision hashed, chained, signed and later anchored
Response to caller Allow reason: "planner holds crm:read; intent matches ticket #4127"
Request flow: a signed request passes four checkpoints — identity, policy, AI judge and ledger — and the caller always receives the decision (allow, deny or escalate) together with the reasoning.

Why AISec

Explain and prove every decision, at every hop.

One checkpoint for every AI→system, system→AI and AI→AI call. Not just at the edge, but on every hop of the chain.

Know who’s really calling

Every agent, tool and service signs its requests with its own key, and the signature is checked again at every hop. Unsigned, replayed or impersonated calls are stopped.

Decisions you can explain

Hard rules first, then an AI judge reviews intent. Every caller gets allow, deny or escalate with a reason, never a silent failure.

History you can prove

Every decision goes into a hash-chained ledger that is regularly anchored to a public blockchain. Anyone with the proof can check it hasn’t been rewritten.

Operator dashboard

Trace any decision to the exact hop.

When agents call agents, things go wrong several steps from where they started. AISec links every hop in a delegation chain, so you can follow a request from the first prompt to the final tool call and see where it was allowed, where it was stopped, and why.

  1. hop 1 user:ops-lead → agent:planner Allow
    Policy
    Signed session; scope agent:invoke; depth 1/4
    AI judge
    Request matches stated task: "summarise Q3 churn by region"
    Ledger
    #48211 · 3a71…0c9d · anchored
  2. hop 2 agent:planner → agent:research Allow
    Policy
    Delegation permitted; scope narrowed to crm:read; depth 2/4
    AI judge
    Sub-task consistent with parent intent
    Ledger
    #48211 · 5be2…77a1 · anchored
  3. hop 3 agent:research → tool:crm.export Deny
    Policy
    Hard deny: crm.export requires crm:export; caller holds crm:read
    AI judge
    Not consulted: a hard deny is final
    Ledger
    #48211 · 9f3c…e1b8 · anchored
  4. hop 4 tool:crm.export → storage:s3-external not executed
  • Hard denies are final. The AI judge can tighten a decision, never loosen one. Hop 3 was stopped by policy before the judge was even asked.
  • Scope narrows as it travels. Each delegation can only pass on what it holds, and chain depth is capped by policy.
  • Every hop has a receipt. Each decision points to its ledger block, so the trace is evidence, not a log you have to trust.

Tamper-evident by construction

A history nobody can quietly rewrite. Including us.

Each block is signed and linked to the one before it. The chain’s roots are published to a public blockchain, so the record can be verified independently of AISec.

  1. Block #48209
    prev
    7c1a…04f2
    hash
    b3e9…91d0
    decisions
    212
    signed
  2. Block #48210
    prev
    b3e9…91d0
    hash
    2f6d…a7c4
    decisions
    187
    signed
  3. Block #48211
    prev
    2f6d…a7c4
    hash
    9f3c…e1b8
    decisions
    240
    signed
  4. Block #48212
    prev
    9f3c…e1b8
    hash
    d04a…3c6e
    decisions
    198
    signed
  5. Anchored
    Merkle root published to a public chain
Each block commits to the one before it. Change any past decision and every later hash breaks, including the root already published on a public chain.

Where AISec fits

Built to sit alongside the tools you already have.

Identity providers know who an agent is. Gateways route traffic. Guardrails filter content. AISec ties these together for each request and keeps proof of every decision.

Typical capabilities by tool category. Individual products vary.
CapabilityIdentity providerAI / API gatewayGuardrail toolsAISec
Verifies the caller Partly covered: At sign-in Partly covered: At the edge Not covered: No Covered: Every hop, signed requests
Enforces scope, rate and delegation depth Partly covered: Scopes Partly covered: Rates and keys Not covered: No Covered: All three, per hop
Checks intent and content Not covered: No Partly covered: Via plugins Covered: Yes Covered: AI judge that can only tighten
Explains the decision to the caller Not covered: No Partly covered: Status code Partly covered: Sometimes Covered: Always, with reasoning
Traces multi-hop agent chains Not covered: No Partly covered: Per-call logs Not covered: No Covered: Hop by hop
History others can verify Partly covered: Audit logs Partly covered: Logs Partly covered: Logs Covered: Hash-chained, publicly anchored

Works with your identity provider, not instead of it

AISec is designed to accept the agent and workload identities you already issue, for example from Microsoft Entra ID, Okta or AWS, and add per-hop signing, policy, explained decisions and a verifiable record on top. Tell us which provider you use when you request a demo.

Put a checkpoint between your AI and everything it touches.

AISec is in early access. Book a 30-minute walkthrough, or join the waitlist and we’ll be in touch.