Architecture Overview

Where Kyra sits

Kyra sits outside the LLM, between the agent's decision to call a tool and the tool's actual execution. The agent reasons normally — Kyra intercepts at the boundary.

Privacy by design: SDK payloads are PII-stripped client-side before transmission. Raw tool call data never reaches Kyra's servers.

Agent (LLM)
    │
    │  "I want to call delete_records()"
    ▼
┌─────────────────────────────────┐
│         Kyra Gate Pipeline      │
│  Gate 1 → Gate 2 → Gate 3 → Gate 4 │
└─────────────────────────────────┘
    │
    │  ALLOW / BLOCK / ESCALATE
    ▼
Tool execution (or halt)

Data flow: SDK layer → [PII strip] → Kyra server

This architecture means:

• Guardrails cannot be "forgotten" by the LLM — they live outside LLM context
• The same enforcement applies to every agent, regardless of framework
• No changes to agent code are required beyond adding the SDK call

Core components

Gate Pipeline

Four gates evaluated in sequence. See Gate Pipeline.

PolicyRAG

A vector store of your organization's policies. Policies are chunked, embedded, and retrieved semantically at Gate 3 evaluation time. Sources include:

• Policies extracted from agent system prompts at registration
• Compliance framework policies (GDPR, HIPAA, SOC2)
• Uploaded policy documents (PDF, Markdown, TXT)
• Policies accepted from the feedback loop

Governance Ledger

An append-only time-series log of every gate evaluation. Fields include: agentId, traceId, mode, outcome, shadowOutcome, tier, aggregateRowsAffected, createdAt. Used for shadow analytics and blast radius tracking.

Audit Trail

A tamper-evident hash chain of every event in a session. Every gate decision, human review, and policy evaluation is logged with a cryptographic link to the previous event. Sessions are fully replayable.

Escalation Engine

High-risk actions (Tier 3/4) that reach Gate 4 are escalated to a human approver. Escalations are routed via Slack and the dashboard. TTL: 24 hours. The agent waits for the decision via SDK polling.

Multi-tenancy

Data is isolated per organization:

• Per-org MongoDB database: kyra_{orgId}
• All collections tenant-scoped: kyra_audit_events, kyra_incidents, escalations, policy_review_proposals
• Shared database (kyra_shared) for policy documents and agent registry only

Modes

Recommended path: start in shadow mode, observe for 1–2 weeks, review proposed policies, switch to enforce.