Tiresias Platform: Architecture Overview

Version: 1.0 Date: March 2026 Classification: Public - Technical Audience Audience: Security architects, CISOs, technical evaluators, compliance officers

Table of Contents

1. Platform Overview
2. System Architecture
3. SoulAuth: Identity & Authorization Engine
4. SoulWatch: Detection & Response Engine
5. SoulGate: API Security Gateway
6. Data Flow: The Closed Loop
7. Security Properties
8. Deployment Models
9. Integration Points
10. Compliance & Audit

1. Platform Overview

Tiresias is an AI agent security platform purpose-built for organizations deploying autonomous AI agents in production. Named after the blind prophet of Greek mythology, Tiresias embodies its namesake's paradox: it sees threats without seeing data. The platform operates on metadata, behavioral patterns, and policy decisions - never on the content of agent communications.

The Problem

AI agents are proliferating across enterprises - orchestrating workflows, accessing APIs, managing infrastructure, and making decisions at machine speed. Traditional security tooling was designed for human users with human-speed interactions. It cannot address:

• Agent identity: How do you authenticate a process that has no password, no biometric, no MFA device?
• Agent authorization: How do you enforce least privilege when an agent's scope changes dynamically?
• Agent behavior: How do you detect a compromised agent when it operates at 1,000 requests per second?
• Agent-to-agent trust: How do you govern delegation chains between autonomous systems?

The Platform

Tiresias answers these questions with three integrated products:

Each product is independently deployable and valuable on its own. Together, they form a closed-loop security system where detection triggers enforcement, enforcement generates audit events, and audit events feed back into detection.

Design Principles

• Zero trust: Every request is evaluated. There is no implicit trust, no ambient authority, no "trusted network."
• Policy as code: All authorization rules are defined in version-controlled YAML, reviewed like application code.
• Deterministic security: Detection and enforcement use rule-based, auditable logic - not opaque ML models.
• Tenant isolation: Every data path is scoped by tenant. No cross-tenant access is architecturally possible.
• Graceful degradation: Component failures reduce capability, never create false positives or security gaps.

2. System Architecture

Tiresias follows a microservices architecture. Each service is stateless (with the exception of short-lived baseline caches), independently deployable, and horizontally scalable.

High-Level Architecture

                         ┌──────────────────────┐
                         │    Portal (Web UI)    │
                         │   React + TypeScript  │
                         └──────────┬───────────┘
                                    │ HTTPS
            ┌───────────────────────┼───────────────────────┐
            │                       │                       │
     ┌──────▼──────┐        ┌──────▼──────┐        ┌──────▼──────┐
     │             │        │             │        │             │
     │  SoulAuth   │        │  SoulWatch  │        │  SoulGate   │
     │  Identity   │◄──────►│  Detection  │        │  Gateway    │
     │  & Auth     │        │  & Response │◄───────│  & Proxy    │
     │             │        │             │        │             │
     └──────┬──────┘        └──────┬──────┘        └──────┬──────┘
            │                       │                       │
            │   ┌───────────────────┤                       │
            │   │                   │                       │
            ▼   ▼                   ▼                       ▼
     ┌─────────────────────────────────────────────────────────┐
     │                    PostgreSQL                           │
     │              (per-tenant isolation)                     │
     └─────────────────────────────────────────────────────────┘

Service Responsibilities

*SoulWatch maintains in-memory behavioral baselines (7-day sliding window). These are rebuilt from the database on cold start, making the service effectively stateless for deployment purposes.

Inter-Service Communication

  ┌──────────┐    Auth request     ┌──────────┐
  │ SoulGate │ ──────────────────► │ SoulAuth │
  └──────────┘    Capability token └──────────┘
       │                                │
       │ Audit events                   │ Audit events
       ▼                                ▼
  ┌──────────┐    Enforcement      ┌──────────┐
  │ SoulWatch│ ──────────────────► │ SoulAuth │
  └──────────┘    (suspend/revoke) └──────────┘

• SoulGate → SoulAuth: Token validation and policy evaluation on every proxied request.
• SoulGate → SoulWatch: Audit events emitted asynchronously on every request.
• SoulWatch → SoulAuth: Enforcement callbacks when threats are detected (key suspension, session termination).
• All services → PostgreSQL: Shared database with row-level tenant isolation.

3. SoulAuth: Identity & Authorization Engine

SoulAuth provides the identity layer for AI agents. It answers two questions for every request: Who is this agent? and What is it allowed to do right now?

3.1 Identity Model

SoulKeys

A SoulKey is the durable credential that establishes an agent's identity. It is conceptually similar to an API key but designed specifically for the agent lifecycle.

Format:  sk_agent_<tenant_prefix>_<persona>_<random_suffix>
Example: sk_agent_acme_orchestrator_x7k2m9p4q1

Credential Security:

Key Lifecycle:

  ┌────────┐     suspend()     ┌───────────┐     revoke()     ┌─────────┐
  │ Active │ ────────────────► │ Suspended │ ────────────────► │ Revoked │
  └────────┘                   └───────────┘                   └─────────┘
       │                            │
       │         reactivate()       │
       │◄───────────────────────────┘
       │
       │         revoke()
       └──────────────────────────────────────────────────────► ┌─────────┐
                                                                │ Revoked │
                                                                └─────────┘

• Active: Key authenticates normally.
• Suspended: Key is temporarily disabled. All requests are rejected. Reversible by an administrator or auto-release timer.
• Revoked: Terminal state. Key is permanently invalidated. Irreversible.

Agent Personas

Each SoulKey is bound to a persona: a named identity with metadata describing the agent's purpose, owner, and operational context. Personas enable policy decisions based on what an agent is, not just what key it presents.

3.2 Policy Decision Point (PDP)

Every authorization request passes through an 8-stage evaluation pipeline:

  Request
    │
    ▼
  ┌─────────────────────────────────────────────────┐
  │  Stage 1: Authentication                        │
  │  Validate SoulKey hash, check lifecycle state   │
  ├─────────────────────────────────────────────────┤
  │  Stage 2: Tenant Resolution                     │
  │  Resolve tenant context, load tenant policies   │
  ├─────────────────────────────────────────────────┤
  │  Stage 3: Policy Lookup                         │
  │  Match request against policy-as-code rules     │
  ├─────────────────────────────────────────────────┤
  │  Stage 4: JIT Constraint Evaluation             │
  │  Time windows, node restrictions, concurrency   │
  ├─────────────────────────────────────────────────┤
  │  Stage 5: Delegation Chain Validation           │
  │  Verify delegation authority and depth limits   │
  ├─────────────────────────────────────────────────┤
  │  Stage 6: Scope Computation                     │
  │  Calculate minimum necessary permissions        │
  ├─────────────────────────────────────────────────┤
  │  Stage 7: Capability Token Issuance             │
  │  Mint short-lived ES256 JWT with computed scope │
  ├─────────────────────────────────────────────────┤
  │  Stage 8: Audit Emission                        │
  │  Log decision to hash-chained audit trail       │
  └─────────────────────────────────────────────────┘
    │
    ▼
  Capability Token (or denial + reason)

Policy-as-Code

Authorization policies are defined in YAML and managed through Git:

# Example policy definition (illustrative)
policy:
  name: data-pipeline-readonly
  version: "1.2"
  effect: allow
  agents:
    personas: [etl-worker, data-validator]
  resources:
    - "storage:read:*"
    - "database:select:analytics.*"
  constraints:
    time_window: "06:00-22:00 UTC"
    max_concurrency: 5
    session_binding: required

Policies are synced from a Git repository, versioned, and applied atomically. Every policy change generates an audit event.

Capability Tokens

When a request is authorized, SoulAuth issues a capability token: a short-lived JWT that encodes exactly what the agent is allowed to do:

Capability tokens are the only mechanism for accessing protected resources. They cannot be forged (asymmetric signature), cannot be reused beyond their TTL, and encode the exact scope granted - not the full set of permissions the agent could have.

JIT Constraints

Just-in-time constraints add temporal and contextual restrictions to authorization decisions:

Delegation Model

Agents can delegate a subset of their privileges to other agents:

  Agent A (orchestrator)
    │
    │  delegate(scope=subset, ttl=300s, depth=1)
    ▼
  Agent B (worker)
    │
    ✗ Agent B cannot further delegate (depth limit reached)

Delegation is:

• Scoped: A delegator cannot grant more than it possesses.
• Time-limited: Delegated authority expires independently of the delegator's session.
• Depth-limited: Configurable maximum delegation chain depth prevents unbounded privilege propagation.
• Audited: Every delegation event is recorded in the hash-chained log.

3.3 Audit Trail

Every authorization decision - grant, denial, key operation, policy change, delegation, enforcement action - is recorded in a tamper-evident audit log.

  Event N-1                    Event N                     Event N+1
  ┌───────────┐               ┌───────────┐               ┌───────────┐
  │ payload   │               │ payload   │               │ payload   │
  │ hash: H1  │──── H1 ─────►│ prev: H1  │──── H2 ─────►│ prev: H2  │
  │           │               │ hash: H2  │               │ hash: H3  │
  └───────────┘               └───────────┘               └───────────┘

• Algorithm: SHA-256 hash chain - each event includes the hash of the previous event.
• Tamper evidence: Modifying any event breaks the chain, detectable by integrity verification.
• Queryable: Filter by tenant, event type, agent identity, time range, severity.
• Exportable: CEF-formatted events for SIEM integration.

4. SoulWatch: Detection & Response Engine

SoulWatch is the platform's detection and response layer. It continuously analyzes agent behavior, applies detection rules, and executes automated response playbooks.

4.1 Detection Pipeline

SoulWatch operates three detection engines in parallel:

  Audit Events
    │
    ├──────────────────┬──────────────────┐
    ▼                  ▼                  ▼
  ┌──────────┐   ┌──────────┐   ┌──────────┐
  │ Anomaly  │   │  Sigma   │   │   Risk   │
  │ Detector │   │  Engine  │   │  Scorer  │
  └────┬─────┘   └────┬─────┘   └────┬─────┘
       │               │              │
       └───────────────┼──────────────┘
                       ▼
                 ┌───────────┐
                 │  Alert    │
                 │  Router   │
                 └─────┬─────┘
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
       ┌─────────┐ ┌────────┐ ┌──────────┐
       │Playbook │ │Quarant.│ │  Notify  │
       │ Engine  │ │ Engine │ │  Router  │
       └─────────┘ └────────┘ └──────────┘

Behavioral Anomaly Detection

SoulWatch maintains a 7-day rolling behavioral baseline for each agent. Incoming activity is compared against this baseline to detect deviations.

8 Anomaly Types:

Baselines are rebuilt from audit data on service restart. When no baseline exists (new agent), SoulWatch operates in learning mode: it collects data without generating anomaly alerts for a configurable warm-up period. This prevents false positives during onboarding.

Sigma Rule Engine

SoulWatch includes a Sigma-compatible rule engine for pattern-based detection. Sigma is an open standard for describing log event patterns, widely used in the security community.

Rule capabilities:

Built-in rule library:

The platform ships with detection rules for common AI agent attack patterns:

• Prompt injection via authentication headers
• Agent impersonation (key reuse from new source)
• Privilege escalation via delegation chain manipulation
• Data exfiltration patterns (high-volume reads followed by outbound transfer)
• Model extraction (systematic API probing)

Organizations can upload custom Sigma rules via the API or Portal UI.

Risk Scoring

Every detection event is assigned a severity level:

Automatic escalation: If the same anomaly type occurs 3 times within a 15-minute window, its severity is automatically bumped one level. This catches slow, persistent attacks that individually register as low-severity events.

4.2 Response Pipeline

Playbook Engine

Detection events trigger response playbooks: automated sequences of actions executed without human intervention (unless an approval gate is configured).

Available actions:

Cooldown windows: Each playbook action has a configurable cooldown period. If the same trigger fires within the cooldown window, the action is suppressed. This prevents response storms: cascading automated actions that amplify an incident rather than containing it.

Approval gates: For critical actions (key revocation, full quarantine), playbooks can be configured to require human approval before execution. The pending action is held in queue with a configurable timeout.

Quarantine Engine

The quarantine engine provides policy-driven incident response with 7 enforcement levels:

Auto-release timers: Reversible enforcement actions can be configured with automatic release timers. This prevents a misconfigured detection rule from permanently locking out a legitimate agent. Example: suspend a key for 30 minutes, then automatically reactivate.

Per-tenant policies: Each tenant configures their own quarantine policies - which enforcement actions are available, which require approval, and what auto-release timers to apply.

4.3 Alert Routing

SoulWatch routes alerts to 8 notification sinks, each with independent configuration:

Routing logic:

• Default routing: Severity-based - critical alerts go to PagerDuty, high to Slack, medium to email.
• Per-tenant overrides: Tenants configure their own routing rules.
• Circuit breakers: Each sink has an independent circuit breaker. If a sink fails repeatedly, it is temporarily disabled to prevent alert delivery delays to other sinks.
• Rate limiting: Per-sink rate limits prevent notification floods.
• Deduplication: Identical alerts within a configurable window are deduplicated. Repeated occurrences trigger escalation rather than repeated notifications.

5. SoulGate: API Security Gateway

SoulGate is a reverse proxy that sits between AI agents and their upstream API providers. Every request passes through a 7-stage security pipeline before reaching the upstream service.

5.1 The 7-Stage Security Pipeline

  Agent Request
    │
    ▼
  ┌─────────────────────────────────────────────┐
  │  Stage 1: AUTHENTICATION                    │
  │  Validate Bearer token or API key           │
  │  Reject: 401 Unauthorized                   │
  ├─────────────────────────────────────────────┤
  │  Stage 2: ACCESS CONTROL                    │
  │  IP allowlist/denylist, geo-restrictions     │
  │  Reject: 403 Forbidden                      │
  ├─────────────────────────────────────────────┤
  │  Stage 3: RATE LIMITING                     │
  │  Sliding window: per-tenant, per-agent,     │
  │  per-endpoint                               │
  │  Reject: 429 Too Many Requests              │
  ├─────────────────────────────────────────────┤
  │  Stage 4: CIRCUIT BREAKER                   │
  │  Upstream health check, failure ratio        │
  │  Reject: 503 Service Unavailable            │
  ├─────────────────────────────────────────────┤
  │  Stage 5: PAYLOAD INSPECTION                │
  │  Prompt injection detection, content policy  │
  │  Reject: 422 with risk assessment           │
  ├─────────────────────────────────────────────┤
  │  Stage 6: UPSTREAM FORWARDING               │
  │  Reverse proxy with connection pooling       │
  │  Pass: Forward request, return response     │
  ├─────────────────────────────────────────────┤
  │  Stage 7: AUDIT LOGGING                     │
  │  Non-blocking event emission                 │
  │  Always: Log request metadata (never body)  │
  └─────────────────────────────────────────────┘
    │
    ▼
  Response to Agent

Each stage can independently reject a request. Rejections include machine-readable error codes and human-readable explanations, but never leak information about downstream services or internal state.

5.2 Prompt Injection Detection

SoulGate's payload inspection stage includes a deterministic prompt injection detector. This is not an ML classifier - it is a rule-based pattern matching engine that produces auditable, explainable results.

Detection Approach

  Request Body
    │
    ▼
  ┌─────────────────────┐
  │  Pattern Matching    │     40+ regex patterns
  │  (OWASP LLM Top 10) │     across 5 categories
  └──────────┬──────────┘
             │
             ▼
  ┌─────────────────────┐
  │  Risk Aggregation   │     Individual severities
  │                     │     combined into score
  └──────────┬──────────┘
             │
             ▼
  ┌─────────────────────┐     score < warn:  pass
  │  Threshold Decision │     score < block: warn + log
  │  (warn / block)     │     score >= block: reject 422
  └─────────────────────┘

Detection Categories

Why Regex, Not ML?

This is a deliberate design choice:

1. Auditability: Every detection can be traced to a specific pattern. SOC analysts can understand why a request was flagged.
2. Determinism: The same input always produces the same result. No model drift, no retraining, no unexplained behavior.
3. Performance: Pattern matching runs in microseconds, adding negligible latency to the proxy pipeline.
4. Extensibility: Organizations add custom patterns via the API. No ML expertise required.
5. Transparency: The full pattern library is inspectable. No black box.

The trade-off is that novel injection techniques may evade regex detection. SoulGate is designed as one layer in a defense-in-depth strategy - behavioral detection in SoulWatch catches attacks that bypass pattern matching.

5.3 Circuit Breaker Design

SoulGate's circuit breaker protects upstream services from cascading failures. However, naive circuit breaker implementations create a security vulnerability: an attacker can deliberately send malformed requests to trip the circuit breaker, effectively DoS-ing the upstream service for all agents.

Anti-weaponization design:

  Standard Circuit Breaker:        SoulGate Circuit Breaker:
  ─────────────────────────        ─────────────────────────
  failures > threshold             failures > threshold
    → OPEN circuit                   AND total_requests > minimum
                                     AND failure_ratio checked PER SOURCE
                                       → OPEN circuit

  Attacker sends 50 bad            Attacker sends 50 bad requests:
  requests → circuit opens          - Their source ratio: 50/50 = 100%
  for ALL agents                    - Overall ratio: 50/1000 = 5%
                                    → Circuit stays CLOSED
                                    → Attacker is rate-limited individually

5.4 Rate Limiting

SoulGate implements sliding window rate limiting at three granularities:

Rate limits are applied from broadest to narrowest. A request that passes tenant limits can still be rejected by agent-level or endpoint-level limits.

6. Data Flow: The Closed Loop

The three Tiresias products form a closed feedback loop where detection drives enforcement, enforcement generates audit events, and audit events feed detection. This is the platform's core architectural insight.

Complete Request Lifecycle

                                    ┌─────────────────┐
                              ┌────►│  SIEM Forward   │
                              │     │  (Splunk, ELK,  │
                              │     │  Sentinel, etc) │
                              │     └─────────────────┘
                              │
  ┌─────────┐   1. Request    │     ┌─────────────────┐
  │  Agent  │ ──────────────► │ ───►│  Notification   │
  └─────────┘                 │     │  (PagerDuty,    │
       ▲                      │     │  Slack, etc)    │
       │                      │     └─────────────────┘
       │ 8. Response          │
       │                      │
  ┌────┴──────────────────────┴──────────────────────────────┐
  │                                                          │
  │   2. SoulGate              3. SoulAuth                   │
  │   ┌───────────┐            ┌───────────┐                 │
  │   │ Inspect   │──auth?───► │ Evaluate  │                 │
  │   │ payload   │◄──token──  │ policy    │                 │
  │   │ proxy req │            │ issue tok │                 │
  │   └─────┬─────┘            └─────┬─────┘                 │
  │         │                        │                       │
  │    4. Audit events          4. Audit events              │
  │         │                        │                       │
  │         └────────┬───────────────┘                       │
  │                  ▼                                       │
  │            5. SoulWatch                                  │
  │            ┌───────────┐                                 │
  │            │ Anomaly   │                                 │
  │            │ Sigma     │                                 │
  │            │ Playbook  │                                 │
  │            │ Quarant.  │                                 │
  │            └─────┬─────┘                                 │
  │                  │                                       │
  │        6. Threat detected?                               │
  │           ┌──────┴──────┐                                │
  │           │ YES         │ NO                             │
  │           ▼             ▼                                │
  │    7a. Enforcement   7b. Continue                        │
  │    ┌───────────┐    monitoring                           │
  │    │ Suspend   │                                         │
  │    │ Revoke    │──── Generates new ──── Back to step 4   │
  │    │ Kill sess │     audit events                        │
  │    └───────────┘                                         │
  │                                                          │
  └──────────────────────────────────────────────────────────┘

Step-by-Step Flow

Why the Closed Loop Matters

Traditional security architectures separate detection from enforcement. A SIEM detects, a human investigates, a human remediates. This works for human-speed threats.

AI agents operate at machine speed. A compromised agent can exfiltrate data, escalate privileges, or pivot laterally in seconds - faster than any human can respond. The closed loop enables:

• Machine-speed response: Detection to enforcement in milliseconds, not minutes.
• Continuous verification: Every enforcement action is itself audited and analyzed.
• Self-limiting errors: Auto-release timers and cooldown windows prevent automated overreaction.
• Complete traceability: The hash-chained audit log captures the entire detection-enforcement sequence.

7. Security Properties

Summary

Graceful Degradation Guarantees

Security systems must fail safely. Tiresias guarantees the following degradation behaviors:

The critical property: SoulAuth fails closed. If the authorization service is unavailable, requests are denied - never silently permitted.

8. Deployment Models

Tiresias supports four deployment topologies to match different organizational requirements:

8.1 SaaS (Managed)

  Your Infrastructure              Tiresias Cloud (tiresias.network)
  ┌─────────────────┐              ┌──────────────────────────────┐
  │  Your Agents    │──── HTTPS ──►│  SoulGate + SoulAuth +      │
  │                 │              │  SoulWatch + Portal          │
  └─────────────────┘              └──────────────────────────────┘

• Fully managed by Saluca LLC
• Multi-tenant with cryptographic isolation
• Automatic updates, scaling, and monitoring
• SOC2-audited infrastructure

8.2 Self-Hosted

  Your Infrastructure
  ┌──────────────────────────────────────────────┐
  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
  │  │ SoulGate │  │ SoulAuth │  │SoulWatch │  │
  │  └──────────┘  └──────────┘  └──────────┘  │
  │  ┌──────────┐  ┌──────────┐                 │
  │  │  Portal  │  │PostgreSQL│                 │
  │  └──────────┘  └──────────┘                 │
  └──────────────────────────────────────────────┘

• Docker Compose or Kubernetes (Helm chart provided)
• Your infrastructure, your data sovereignty
• License key activation
• You manage updates and scaling

8.3 Hybrid

  Your Infrastructure              Tiresias Cloud
  ┌─────────────────┐              ┌──────────────────┐
  │  ┌──────────┐   │              │  ┌──────────┐    │
  │  │ SoulGate │   │── policy ───►│  │ SoulAuth │    │
  │  │ (local)  │   │◄── tokens ──│  │ (SaaS)   │    │
  │  └──────────┘   │              │  └──────────┘    │
  │                 │              │  ┌──────────┐    │
  │  Your Agents    │              │  │SoulWatch │    │
  │                 │              │  │ (SaaS)   │    │
  └─────────────────┘              └──────────────────┘

• SoulGate deployed on-premise (gateway close to your workloads, minimal latency)
• SoulAuth and SoulWatch managed in Tiresias Cloud
• Agent traffic stays in your network; only auth decisions and audit events traverse the boundary
• Best of both: local data path performance with managed security intelligence

8.4 Local Development

export SOULAUTH_MODE=local
./tiresias serve
# → SQLite database, zero external dependencies
# → Single binary, localhost:8080

• Zero-config single binary for development and testing
• SQLite storage (no PostgreSQL required)
• Full API compatibility with production
• Not for production use

9. Integration Points

SIEM Integration

All SIEM integrations include:

• Configurable event filtering (by severity, type, tenant)
• Dead-letter queue for delivery failures
• Automatic retry with exponential backoff
• Integrity verification metadata (hash chain references)

Notification Sinks

Policy Source

Policies are synced from a Git repository:

Policy sync is pull-based with configurable intervals or webhook-triggered on push.

Billing

Metered billing tracks active agent count per billing period. No per-request charges.

Identity Provider (SSO)

SSO governs access to the Portal (human users). Agent authentication uses SoulKeys exclusively.

Observability

10. Compliance & Audit

Audit Log Retention

Hash-Chain Integrity Verification

The audit log supports on-demand integrity verification:

  Verification Request
    │
    ▼
  ┌─────────────────────────────┐
  │  1. Select event range      │
  │  2. Recompute hash chain    │
  │  3. Compare against stored  │
  │  4. Report: PASS or TAMPER  │
  └─────────────────────────────┘

Verification can be triggered via API, scheduled as a recurring job, or run on-demand from the Portal. Results are themselves audit-logged (the verification event is part of the chain).

Compliance Framework Support

Report Generation

Tiresias generates compliance-ready reports on demand:

• Access control report: All agents, their permissions, and policy bindings
• Incident report: Detection events, response actions, resolution timeline
• Audit trail export: CEF-formatted event stream for external audit tools
• Policy change log: Version-controlled history of all authorization policy modifications

Event Format

All events follow the Common Event Format (CEF) standard for interoperability with enterprise security tooling:

CEF:0|Tiresias|SoulAuth|1.0|AUTH_GRANT|Agent Authorized|3|
  src=agent:orchestrator-01
  dst=resource:storage:read:analytics
  outcome=success
  reason=policy:data-pipeline-readonly
  chain_hash=sha256:a1b2c3...

Appendix A: Glossary

Appendix B: API Surface Summary

Tiresias is developed by Saluca LLC. For technical questions, contact security@saluca.com. Document version 1.0 - March 2026