Built for GDPR EU AI Act NIS-2 DORA
Kyde
Zero Trust
AI can act. Make sure every action is under control.
The zero trust layer for AI workers and agents. Kyde sits between them and the models, tools and business systems they reach.
Identity · Policy · Data · Limits · Evidence
Traditional security was built around access.
Controls people, devices and networks. Verifies who is connecting, from what, to which resource.
What the AI actually does. The connection was authorized hours ago. The action is the thing that needs verifying, every time, on its own.
Trust every action, not just every connection.
Workers we build and AI you already run cross the same layer. Whichever you start with, the controls and the record are the same.
- Every worker has an identity.
- Every action is checked.
- Every action is recorded.
FIG.1 · The layer is wider than what stands on it.
One control layer for every AI action.
Know who is acting.
Every worker and every agent carries a name of its own, not a shared key that four systems use.
Decide what it can do.
Rules are checked before the action executes, not written up in a report afterwards.
Control what it can see.
Sensitive fields are masked inline, before they ever reach a model.
Control how far it can go.
Spend, volume and reach held across a run, not just per call. Coming soon.
Prove what happened.
A hash-chained record written at the boundary, which your auditor recomputes without us.
From control to proof.
Record every AI action.
Humans · Agents · Tool calls · Approvals
Every action an AI system takes crosses one layer, and that is where it stops being traffic and becomes a record. Who acted, under whose identity, against which model, reaching which system. Written as it passes, not reconstructed afterwards from four vendor consoles that each saw a different part of it.
FIG.2 · Every step appends a link. The work writes the record as it happens.
Five of these seven run under an id nobody has claimed.
Find the agents nobody put on a list.
Scanning does not stop after the first sweep.
Identity · Provider · Model · Reach
Most agents run under a shared API key, indistinguishable from each other and from the people whose credentials they borrowed. Kyde gives each one an identity of its own, so every action carries a name before it happens and the inventory builds itself: which providers, which models, which tools each agent reaches. A new agent appears on the board the first time it acts.
Govern every action before it happens.
Policy is evaluated at the point of action, not in a report afterwards.
Inline DLP, policy blocks, agent and MCP blocking.
No customer export. No payment over 100 euros without approval. No HR data to an external service. No MCP tool outside its mandate. You already run on rules like these. Kyde turns them into policy every worker passes before it acts, not a report you read afterwards. Observe first, enforce when ready. All of this runs in production today.
The blocked action stops at the policy line, not inside your systems.
Seven cases come out the way the record says they should. The eighth is the one worth finding, and only the recording makes it findable.
Rerun the past against the present.
Models change under the same name. Policies change. Nothing announces it.
Replay a recorded run against today's models and policies.
A recorded run is a hundred real cases where the right answer is already known. Replay it against what would happen today and the difference is something you can point at, instead of a complaint that arrives six weeks later. The same recording is what continuous evaluation runs on: measured against the outcome in your system of record, not against what a person happened to click. Replay runs today. Continuous evaluation is coming soon.
Evidence the other side can check without you.
Who acted, which agent, which model, under which policy.
Every entry is hash-chained at the boundary, before anything reaches a provider, and held outside the reach of the thing being recorded. Altering one link breaks every link after it, and an auditor recomputes the chain offline, without us in the room. Your provider's log lives on their infrastructure and is read through their console. In a dispute that involves them, it is theirs, not yours.
The export is recomputed on the other side. Everything after the boundary happens without us, and nothing comes back.
One layer. Four things it is worth.
AI audit trail
Continuous evidence for regulated AI systems.
A hash-chained record written at the boundary, exported as a dated document an auditor recomputes offline. Built against GDPR, the EU AI Act, NIS-2 and DORA.
Read on → For insuranceAI telemetry
Observe how AI actually behaves in production.
Not what a system was designed to do, and not what a questionnaire says it does. What it did: which actions, against which systems, how often, and how much of that was ever recorded.
Read on → For AI governanceContinuous evals
Measure whether AI stays reliable as models, data and workflows change.
A recorded run is a set of real cases with known outcomes. Re-run them when a model ships and the drift is a number rather than an anecdote from a support ticket.
Read on → For incident & riskReplay
Reconstruct and rerun what happened.
A model swapped under the same name does not announce itself. Replaying a recorded run against the present turns "something changed" into a difference you can point at.
Read on →Built for independent verification.
Evidence you cannot check yourself is a claim. Every part of the record is built so somebody outside this company, and outside your company, can arrive at the same answer without asking either of us.
- Hash chain
- Each entry carries the hash of the one before it. Altering a single entry breaks every link after it.
- Append-only
- Entries are written at the boundary as the action passes, and held outside the reach of the system being recorded.
- Offline recomputation
- An auditor recomputes the chain from the exported document, on their own machine, with us not in the room.
- Open-source gateway
- The gateway and the ledger are open source, so the thing writing the record can be read. github.com/kydehq/gateway →
- Ed25519 signing
- Signing each entry proves authorship rather than order. An Enterprise capability.
- Your keys
- Signing keys are yours and stay in your environment. A record we could produce on your behalf is a record we could also alter.
AI should earn autonomy.
Start with limited responsibility. Increase it as the worker proves it can operate reliably.
Reading? Suggesting? Calling tools? Running workflows? Approving payments? Running unattended? Every one of those is a different amount of trust, and most organizations grant them all at once, on the day the agent is switched on, because there is nothing to grant them against.
Kyde ties each step to the record. A rung is held because the record shows it was held, and a worker that stops producing that evidence comes back down. Six levels, L0 to L5, from a worker that only reads to one running unattended.
FIG.3 · Six levels, L0 to L5. Every step climbed on evidence, every step recorded, and from L4 upwards observation alone no longer qualifies.
The record belongs to you
Your models will change.
Your record shouldn't.
Models change, frameworks change, vendors change, people leave. Kyde sits in your layer rather than theirs. What matters on the day a provider disappears is whether your work keeps running and the record is still yours to produce.