Security at Taos
We're a security product. That means we hold ourselves to the standard we sell.
The team has worked inside the compliance regimes Taos is designed to serve — SOC 2, SOX, PCI-DSS, ISO 27001, NIST 800-53. We know what auditors actually look for and what "we log everything" looks like when it hasn't been tested under subpoena. That experience is in the architecture, not the marketing copy.
Your data never leaves your network
This is a hard guarantee, not a configuration option. The Taos kernel runs inside your network. It does not call home with operational data. The Taos SaaS control plane handles bootstrap only — workflow definitions and tool registry metadata. User identities, workflow inputs and outputs, tool credentials, and delegation chains never cross the boundary. If you're in a regulated industry, that's not a feature — it's the minimum bar.
No customer data — identities, PII, credentials, or workflow payloads — ever crosses the on-prem boundary. Enforced architecturally, not by policy.
The kernel bootstrap token authenticates to the Taos API for registry sync only. The OBO signing key is generated by you, stays in your network, and Taos never sees it.
Once bootstrapped, the kernel operates with no outbound connectivity. Designed for FedRAMP High and classified workload environments.
Audit that holds up under examination
Most systems log after the fact. We've seen what happens when an incident response team discovers the logging pipeline failed silently three weeks earlier. Taos writes the audit record before the tool call is dispatched — if the write fails, the operation doesn't proceed. The log is hash-chained and sealed with Ed25519 signatures. An auditor with offline access to the exported records can verify the chain without touching the kernel.
Audit records are fsync'd to disk before dispatch. A committed operation always has a prior tamper-evident record. No gaps by design.
Each record is signed with the kernel's Ed25519 signing key. Signatures are verifiable offline — useful when your auditors want evidence you can't have altered after the fact.
Each record includes the hash of its predecessor. Deletion or modification breaks the chain. This is how you satisfy the 'tamper-evident' requirement in SOX §404 and HIPAA §164.312(b).
Records stream to a Maildir sink for pickup by Splunk, Microsoft Sentinel, or any Kafka-compatible pipeline. Your existing SIEM investment works.
Credentials that expire by design
Shared secrets and long-lived credentials are how breaches persist. Taos agents never hold credentials directly. The kernel mints short-lived Agent Runtime Tokens scoped to a single execution session. Tool credentials are injected at dispatch time from the kernel vault — they don't travel through agent context where an LLM could observe them. Key rotation doesn't break in-flight workflows.
ARTs are valid for 5 minutes, scoped to a single workflow execution, and embed the signed policy decision. Workers verify the signature — no re-evaluation, no policy bypass.
Every tool call carries the full cryptographic delegation chain: human → agent → tool. The chain is auditable at every link. This is how you prove who actually authorized a $2.3M payment.
HashiCorp Vault, AWS Secrets Manager, or the built-in encrypted store — your choice. Rotation is live: in-flight workflows continue with the key version they were issued.
Tool credentials are never in the data that reaches the LLM. An agent that gets prompt-injected cannot exfiltrate credentials it was never given.
Policy enforcement at execution time
Guardrails on model output and observability after the fact are useful. They are not the same as enforcement. Taos evaluates policy at the moment of execution — before the tool call is made — using Rego (OPA). Rules are written as code, reviewed like code, and validated with a linter before deployment. Hot-reload means you can push a policy change without a kernel restart or a deployment window.
If policy evaluation fails or returns an unrecognized result, the step is denied. There is no implicit allow. No fallback.
allow, deny, require_manual_approval, require_group_approval, require_separation_of_duties, not_applicable. Auditors can read the decision from the audit record without ambiguity.
Rego bundles are validated with Regal (linter) and Regorus shape-check before deployment. Policy changes go through your existing code review process.
Every step that can be compensated must declare its rollback at design time. Absence of a compensation block is a schema validation error. You can't ship a workflow that silently orphans state.
Compliance frameworks we know from the inside
These aren't checkboxes we're working toward. They're the design constraints the system was built around. The team has worked in environments where these frameworks had real consequences — audits, fines, incident response — and that experience is reflected in architectural decisions, not marketing copy.
In progress. The audit log architecture, access control model, and change management process are built to satisfy Trust Services Criteria CC6, CC7, and A1.
Dual-authorization enforcement, tamper-evident audit trail, and separation of duties are first-class concepts — not compensating controls bolted on later.
PHI never enters agent context. PII tokenization replaces sensitive values before any LLM call. Per-session data access records satisfy the audit control requirements.
Cardholder data isolation, least-privilege credential scoping, and tamper-evident logging align with Requirements 3, 7, and 10.
Asset management, access control, and cryptography controls map directly to Annex A domains. The kernel vault and OBO architecture were designed with A.10 and A.9 in mind.
Audit and accountability (AU), identification and authentication (IA), and access enforcement (AC) controls are addressed architecturally. FedRAMP High baseline is the deployment target.
Security contact
Report a vulnerability or request our security documentation package
contact@predictable.sh