Request a demo

Security & trust

You’re putting us in the path of your AI. Here’s why that’s safe.

AISec sits on the critical path between your AI and your systems, so it has to be held to a higher standard than the things it protects. These are the principles we build to.

Fail closed

If a check can’t complete (a bad signature, an unknown caller, a condition that can’t be evaluated) the request is denied or escalated. Never quietly allowed. If the AI judge is unreachable, a fallback judge takes over.

Default deny, least privilege

Nothing is allowed unless a rule allows it. Rules are per caller and per action, and the depth of a delegation chain is capped.

Private keys stay with you

Callers sign requests with their own keys. AISec only ever needs the public key, so it can’t impersonate your agents.

AI adds safety, never removes it

The AI judge can tighten a decision but never loosen one, and hard denies never reach it. A fooled model can’t unlock anything.

Verifiable, not just trusted

Decisions are hash-chained into signed blocks, designed to be anchored to a public blockchain, so you and your auditors can check the record without taking our word for it.

Minimal data

The ledger stores decisions, reasons and fingerprints. Only hashes are anchored; request content never goes on a blockchain.

Your data can stay with you

The AI judge runs on an open-weight safety model that can run on your own infrastructure, so request content doesn’t have to leave your environment to be judged.

Threat model

What we defend against, and what remains.

A high-level view. No system removes every risk, so for each threat we also state what is left for you to manage.

  1. Impersonating an agent or service

    How AISec addresses it
    Every request is signed with the caller’s Ed25519 key and checked against its registered public key. Keys can be rotated and revoked.
    What remains
    A stolen private key works until it is revoked. Keep keys in a secret store or HSM.

  2. Replaying a captured request

    How AISec addresses it
    Each request carries a one-time nonce and a timestamp; repeats and stale requests are rejected.
    What remains
    Requires reasonably synchronised clocks on callers.

  3. Prompt injection that triggers tool misuse

    How AISec addresses it
    Deterministic rules limit what any caller can do, whatever the model says. The AI judge flags calls whose intent doesn’t match the task.
    What remains
    Misuse within an allowed scope is still possible. Keep scopes narrow and escalate sensitive actions.

  4. Privilege escalation through delegation (confused deputy)

    How AISec addresses it
    Each hop is signed and linked to its parent, policy caps chain depth, and rules can require a human for sensitive actions inside a chain. The AI judge checks that each hop still serves the original task.
    What remains
    Broad rules for an agent apply wherever it sits in a chain. Keep rules narrow.

  5. Manipulating the AI judge

    How AISec addresses it
    The judge can only make decisions stricter, never looser. Deny rules are final before it runs, and request content is treated as untrusted data, never as instructions.
    What remains
    A manipulated judge could miss a problem the rules also allow; it can never create access.

  6. Rewriting history, including by an insider or by us

    How AISec addresses it
    Records are hash-chained into signed blocks, and AISec is designed to anchor their roots to a public blockchain. Any later change breaks the chain.
    What remains
    Records newer than the last anchor rely on block signatures until the next anchor is published.

  7. Gateway outage or overload

    How AISec addresses it
    Fail-closed behaviour plus rate limits per caller; the gateway is designed to run redundantly.
    What remains
    An outage blocks AI actions rather than letting them through unchecked. That is deliberate.

Check it yourself

Verification is a button, not a promise.

In the dashboard, anyone with access can recompute the whole ledger and compare anchored blocks with what is on the blockchain.

Audit ledger page with “Matches the blockchain” and “Chain intact” results, the anchoring contract and recent blocks with Merkle roots.
Every hash, link, Merkle root and signature is recomputed. The demo anchors to a local test chain.

Our posture

Honest about where we are.

Today

  • AISec is in early access, built by a company based in the Netherlands.
  • We don’t hold security certifications yet. We’ll list them here when we do, and not before.
  • We work with early-access customers under a written agreement covering data handling.

This website

  • Static pages only: no cookies, no analytics, no third-party scripts or fonts.
  • A strict Content Security Policy, HSTS and other security headers on every response.
  • A machine-readable security contact at /.well-known/security.txt.

Found something?

Report a vulnerability.

We welcome reports from security researchers and will work with you to fix issues quickly and credit you if you wish.

Read our disclosure policy security@aisec.design