Skip to main content
Hexr is built on the principle that security for AI agents requires more than network firewalls and access keys. Every agent you deploy gets six overlapping security layers — cryptographic identity, mutual TLS, per-process authorization policies, short-lived credentials, GenAI threat scanning, and hardware-level code isolation — working together so that a failure in one layer doesn’t expose your systems to the next threat.

​
Three core principles

  1. Identity-first — every process has a unique cryptographic SPIFFE identity, so authorization decisions are always based on verified identity, never assumed context
  2. Zero standing access — credentials are short-lived (15-60 minutes) and scoped to the minimum required — no long-lived keys, no shared secrets
  3. Defense-in-depth — multiple independent layers mean no single misconfiguration or compromised component puts everything at risk

​
Six security layers

SPIFFE/SPIRE — Every agent process gets a unique X.509 SVID issued by SPIRE. This is per-process identity, not just per-pod, so individual sub-agents within a multi-agent framework each have their own cryptographic proof of identity.
Envoy mTLS — All traffic between your agents and platform services uses mutual TLS, with certificates sourced directly from SPIRE. Your agent code never manages certificates — Envoy handles the entire TLS lifecycle.
OPA policies — Every request to a cloud service or platform API is evaluated against Rego policies that you define. Authorization decisions are made per-process — not per-tenant or per-pod — using the agent’s verified SPIFFE ID.
Credential Injector — Cloud credentials are issued with 15-60 minute TTLs, scoped to the requesting process’s identity, and cached in a three-tier system. No long-lived keys exist anywhere in your deployment.
LLM Guard — Prompts and LLM outputs are scanned for injection attempts, PII leakage, hardcoded secrets, and invisible text attacks before reaching your agent’s logic or leaving your system.
Firecracker sandbox — Code generated or executed by your agents runs inside Firecracker microVMs with hardware-level isolation, no network access, and resource limits. Kubernetes namespaces provide tenant-level isolation — your workloads never share infrastructure with other tenants.
The layers form a chain: 
Identity (SPIRE) → Transport (mTLS) → Authorization (OPA) → Credentials → GenAI Guard → Sandbox Isolation

​
What each layer protects you from

LayerThreatHow Hexr protects you
SPIFFE identityImpersonation, unauthorized accessCryptographic proof of identity — no assumed trust
mTLSEavesdropping, man-in-the-middle attacksAll traffic encrypted with X.509 certificates
OPA policiesOverprivileged agents, unauthorized tool accessPer-process, per-service authorization on every call
Credential InjectorCredential leakage, long-lived key exposure15-minute tokens, auto-rotated, never stored in code
LLM GuardPrompt injection, PII leakage in outputsMulti-scanner pipeline on every prompt and response
Firecracker sandboxCode execution escapeHardware-level microVM isolation
NamespacesCross-tenant data accessKubernetes namespace isolation per tenant

​
Compliance readiness

FrameworkStatus
OWASP Top 10 for GenAIAll 10 risks addressed
SOC 2 Type IIArchitecture designed for compliance
NIST AI RMFIdentity and risk controls aligned
GDPRPII scanning, data isolation per tenant
HIPAAEncryption at rest and in transit
See Compliance frameworks for the detailed control mapping.

​
Explore the security model in depth

SPIFFE identity

How per-process cryptographic identity works and what it gives you.

OPA policies

Write and deploy Rego authorization policies for your agents.

Threat model

Agent-specific attack chains and how each one is mitigated.

Compliance frameworks

SOC 2, NIST, GDPR, and HIPAA control mappings.