Pramiti Docs

Security Model

Assume-breach design, fail-closed, Ed25519 attestation chain

Pramiti's security model is built on the assumption that the LLM will be compromised. Enforcement is external to the model, deterministic, and operates at the action layer.

Assume Breach

The core design principle: prompt injection may never be fully patched. Therefore:

  • The LLM is treated as an untrusted component
  • All enforcement happens outside the LLM, in deterministic code
  • The policy engine has no LLM dependency — same inputs always produce same outputs
  • SQL validation runs against the actual schema, not LLM-generated metadata

Fail-Closed Design

When components fail, the system blocks rather than allows:

FailureBehavior
Policy engine cannot evaluateDefault verdict: DENY
LLM unavailableReturn "I cannot answer" (not a guess)
Schema drift detectedConfidence scores degrade
Attestation signing failsAction blocked
Database unavailableAll requests fail (no cache fallback for writes)

Authentication

API Authentication

MethodMechanismUse Case
JWTepistom_token cookie or Authorization: Bearer headerBrowser and programmatic access
API Keysek_* prefix, SHA-256 hashedProgrammatic access with per-key rate limits
SAML SSOStandard SAML 2.0 flowEnterprise SSO
Azure ADOAuth 2.0 OIDCMicrosoft ecosystem
Demo modeX-Demo-User headerLocal development only

CSRF Protection

Active when auth_mode != "demo". Frontend sends X-Epistom-CSRF: 1 on mutating methods.

Rate Limiting

Per-key rate limiting with priority resolution:

  1. Demo user header (demo mode)
  2. API key hash (SHA-256 prefix)
  3. X-Forwarded-For header
  4. Remote IP address

Redis is required for consistent rate limiting across multiple API pods.

Attestation Chain

Every Aegis decision produces an Ed25519-signed attestation record:

  1. Payload hashing — SHA-256 of the action arguments
  2. Impact hashing — SHA-256 of the blast radius computation
  3. Message construction — Deterministic concatenation of all material fields
  4. Ed25519 signing — Asymmetric signature (customers cannot forge)
  5. Append-only storage — Database trigger prevents UPDATE/DELETE

The attestation includes: verdict, tool name, agent ID, payload hash, impact hash, constraint IDs, delegation fields, evidence classification, and timestamp.

Audit Trail

Two append-only tables provide a complete audit trail:

TableProtectionContent
aegis_attestationsDatabase trigger + Ed25519Every policy decision
audit_logsDatabase trigger + HMAC-SHA256Every API request

Both tables prevent UPDATE and DELETE at the database level. Even a database administrator with direct SQL access cannot modify records.

Safety Invariant (SI-1)

Auto-resolved entities are read-only. Writes require steward-confirmed resolution.

This prevents agents from acting on potentially incorrect semantic mappings that were auto-discovered but not yet verified by a human.

Credential Security

  • Connection credentials are encrypted at rest with Fernet encryption
  • Signing keys are stored as environment variables or Kubernetes secrets
  • API keys are stored as SHA-256 hashes (plaintext never persisted after creation)
  • SAML SP certificates use dedicated file paths, not environment variables

On this page