The Zero-Trust
AI Stack.
Securing the Agentic Economy
[KYDE]
The Zero-Trust AI Stack sits between your agents and every LLM provider. Every agent gets a cryptographic identity, enforced behavioral scope, and a court-ready evidence trail — without touching a single line of agent code.
<100ms
Target latency
100%
Planned provider coverage
0
Code changes by design
Questions most enterprises
can't answer.
Who acted?
Agents share service accounts with broad permissions. No traceable identity. No role boundaries. A support agent scoped for €500 refunds issues €5,000 because nobody scoped its authority.
Why did it decide that?
An HR agent retrieves a policy document from 2022 and uses it to guide a termination. The current policy says something different. Nobody logged which source it relied on.
What are the boundaries?
Token budgets don't exist. API access is unrestricted. An intern's research agent burns through your entire monthly token allocation while your production agents queue.
What happened?
A procurement agent posts confidential contract terms in Slack. Leadership needs the full evidence trail. The logs are vendor-provided, self-reported, software-only. A compromised host can rewrite them silently.
Who governs the chain?
An agent raises a price in Salesforce, triggers a payment in Stripe, and updates inventory in SAP. Each vendor logs their own system. Nobody logs the complete workflow. When the chain breaks, you have fragmented logs across ten consoles — and zero cross-system governance.
Resilient organizations don't just detect these failures.
They architect systems that prevent them.
The proxy intercepts. Signs. Chains. Forwards.
KYDE runs as a local or hosted HTTP proxy, fully compatible with the OpenAI API schema. Any agent that can be pointed at a base URL can be governed.
$ export OPENAI_BASE_URL=https://kyde.intranet/v1
Target deployment: one environment variable. Designed for zero code changes.
Intercept
Every request from every agent routes through the proxy. The agent sees no difference.
Register
The request is matched to an agent identity and role. Budget and policy checks run before the call is forwarded.
Sign & Chain
An Ed25519-signed, SHA-256 hash-chained entry is written. Alter any record — every subsequent link breaks.
Forward
The original request continues to the LLM provider. Target added latency: under 100ms.
Full fleet visibility. One view.
Every agent, session, and action across your infrastructure — mapped, logged, and auditable from a single dashboard.
Data Integrity Audit Dashboard
Agent Behavioral Ledger
- Overview
- Data Integrity
- Entry Timeline
- Sessions
- Token Analysis
- Agent Topology
- DLP Alerts
- DLP Rules
- Users
- Settings
192.168.68.0/24
RFC1918 (corporate private) — activity in the last 24 hours
Agents (3)
Agent
Role
Upstreams
Req.
Last seen
agent:b6068d94edf0
customer_facing
anthropic
6
12:45:53
agent:a2f1c8b3d7e9
infrastructure
openai
24
12:44:11
agent:9e4d2c1f6a8b
intern_sandbox
openai
3
12:39:07
Recent Sessions (3)
Session
Model
Req.
Last seen
s-5944d14b2406
claude-sonnet-4-6
4
12:45:53
s-3c1700ddb97e
claude-haiku-4-5
1
12:45:34
session:b878a6801d9a9e68
gpt-4o
1
12:39:07
Every entry answers five questions.
Who
Agent ID, role, machine ID, user identity
What
Prompt, model, tool calls, response
Why
Last 5 messages as causal context
When
Millisecond-precise UTC timestamp
Proof
Ed25519 signature + SHA-256 hash chain link
{
"entry_id": "e_7f3a2b1c",
"sequence": 1847,
"agent_id": "sales_bot_prod",
"role": "customer_facing",
"timestamp": "2026-03-15T14:23:07Z",
"action": "chat.completion",
"provider": "openai",
"model": "gpt-4o",
"tool_calls": ["crm.update_deal", "slack.send_message"],
"input_hash": "sha256:9f86d0...",
"entry_hash": "sha256:7b2e4d...",
"prev_hash": "sha256:1c3f8a...",
"signature": "ed25519:Mk3nR9..."
}Roles. Budgets. Boundaries. Per agent.
Every agent in your fleet gets a distinct identity and an assigned role. Roles determine what an agent is permitted to do — and what it costs you when it does it.
Identity & Roles
Register every agent with a unique ID. Assign roles — infrastructure, customer_facing, internal_research, intern_sandbox. Roles carry permissions, not agents.
Priority & Resource Allocation
Your production infrastructure agent gets priority over your intern's research bot. When token budgets run tight, critical agents aren't the ones that queue.
Token & Cost Budgets
Set hard limits per agent, per role, or per team. Daily, weekly, monthly. No agent runs up a bill you didn't scope.
API Allowlists & Blocklists
Define which endpoints each role is permitted to reach. Your billing agent talks to the payment API. Your support agent doesn't.
Behavioral Baselines & Anomaly Detection
Kyde learns what normal looks like for each role. When an agent deviates — unusual call volume, unexpected endpoints, out-of-pattern tool usage — you get alerted before it becomes an incident.
Gateway, not endpoint.
KYDE — Gateway Model
Agent A ──┐
Agent B ──┼──► KYDE ──► LLM API
Agent C ──┘
↓
Central DB · One record
- One deployment covers the entire fleet
- Built to support every agent, framework, and LLM
- Central visibility — no aggregation required
- No per-agent installation or configuration
Endpoint / Runtime Solutions
Agent A + Runtime ──► LLM API ↓ Log A
Agent B + Runtime ──► LLM API ↓ Log B
Agent C + Runtime ──► LLM API ↓ Log C
- Install on every agent separately
- Framework- and runtime-specific
- Fragmented logs — difficult to aggregate
Property
KYDE
Endpoint Solutions
Deployment effort
One ENV variable
Per-agent installation
Agent coverage
All agents, automatically
Each agent separately
Fleet management
Central roles, budgets, policies
Per-agent configuration
Audit trail
Single, tamper-evident record
Fragmented per agent
Code changes needed
None
Typically required
Root of trust.
From software to silicon.
Each entry is signed with an Ed25519 keypair generated locally on first initialization. The hash chain ensures sequential integrity — tamper with any single entry, and every subsequent link breaks.
For environments where software-only signing isn't enough, Kyde's architecture is built for hardware-rooted attestation from day one.
No re-architecture required between levels. Same API. Same data format. Same evidence chain. The root of trust gets deeper — the interface stays the same.
Level
Mechanism
Status
Ed25519 Signed
Cryptographic signing at the point of capture — core to the current development phase.
TPM / HSM
Military-grade hardware isolation. Signing keys never exposed to host OS.
TEE (TDX/SEV-SNP)
Trusted Execution Environment attestation for maximum integrity.
FIPS 140-3
Architecture designed for FIPS-validated cryptographic modules.
Three guarantees. One stack.
Not a roadmap. A complete infrastructure layer that ships as a unit — covering every agent from day one.
SCOPE
No agent acts without ID & clearance.
Every action checked against policy before execution. Scope enforced at the proxy — not by trust.
- Cryptographic agent identity & role assignment
- Behavioral scope — API allowlists per role
- Token & cost budgets enforced pre-call
- Hard circuit breakers before external systems
- Provider-agnostic — every model, every provider
TRACE
No incident without accountability.
Every incident traced to a single agent identity. Full chain reconstruction: source, path, destination.
- Every action traced to a specific agent
- Causal context — last 5 messages per tool call
- Full decision chain reconstruction
- Behavioral anomaly detection & alerting
- SOC-ready triage dashboard for centralized alert investigation
- Continuous data integrity verification
PROVE
Court-ready cryptographic audit trail.
Every entry signed. Provider-independent. Regulator-ready export on demand.
- Ed25519-signed append-only ledger
- Tamper-evident — alter any entry, every link breaks
- Independent of LLM provider infrastructure
- NIS-2, DORA, EU AI Act evidence trail
Optional High-Security Layer
Military-grade hardware isolation via TPM/HSM — signing keys never exposed to the host OS. For regulated environments where software-only signing isn't enough.
One environment variable.
Designed for 0 code changes.
The stack sits outside your agent. It cannot be overridden by agent code — and it requires none. Any agent that can be pointed at a base URL is governed, immediately.
Sits outside the agent
Cannot be overridden by agent logic or bypassed by agent code.
No SDK dependency
No library to install, no wrapper to integrate, no runtime to manage.
Framework-agnostic
LangChain, AutoGen, CrewAI, custom — governed equally with one ENV variable.
Targeting under 100ms latency
Governance is designed to be invisible to agent code and end users.
↳ Before vs. After
Install SDK on every agent
One ENV variable or Group Policy push
Framework-specific integration
Any base URL — every agent, every framework
Governance logic in agent code
Governance outside the agent. Immovable.
Re-integrate when model changes
Zero changes when switching providers
Three ways to deploy.
Environment Variable
Point any agent at the proxy with one ENV variable. Ideal for local development or single-machine deployments.
Group Policy
Push a single GPO that redirects all LLM API traffic through KYDE. No developer action, no application changes, no opt-in required.
Hosted Proxy
Managed deployment. Traffic routes through Kyde's infrastructure. Data-residency options available for EU-regulated environments.
Provider-agnostic. Zero SDK changes required.
Provider
Status
OpenAI (GPT-4o, o1, o3)
Anthropic (all models)
Azure OpenAI
DeepSeek
Mistral / Ollama / Local
Google Gemini (via OpenAI compat.)
Governing the Chain.
Enterprises don't run on one vendor's stack. Your agents shouldn't be governed by one either. Kyde governs the entire execution chain — across MCP servers, legacy APIs, and third-party platforms like Salesforce, SAP, and Stripe. We don't just log the LLM completion. We govern the operational consequence.
Every major vendor governs their own stack. Nobody governs what happens between stacks — until now.
Action type
Governed
LLM Call
chat.completion, embeddings, any model request
MCP Tool Call
crm.update, slack.send, db.query via MCP server
Internal API
REST/gRPC calls made by agents to internal systems
Agent-to-Agent
Delegation and sub-agent invocation
External Service
Third-party API calls routed through the proxy