Security Practices

Architecture Security

Intercis operates as an external policy enforcement layer, sitting outside the AI agent process. This architectural decision matters because the enforcement layer runs as a separate process from the agent: a compromised agent has no path to rewrite a verdict Intercis has already returned. Routing itself is a configuration setting, though — a fully compromised process can repoint its API base URL away from the proxy, so this property is a true tamper-resistance guarantee only when Intercis is paired with network egress control that forces provider traffic through it.

External Enforcement

• No code changes required. Agents point to a different API endpoint instead of the LLM provider directly. Intercis sits in the middle, transparent to your application.
• Control plane isolation. The policy engine, audit system, and enforcement layer run in a separate process from agent infrastructure, so a compromised agent cannot rewrite a verdict or reach the audit log directly. Keeping that agent from routing around the proxy entirely is a separate control — network egress control; see the threat model below.
• Zero trust enforcement. Every governed request that reaches the proxy is authenticated by its x-intercis-key header before any policy runs; a missing or wrong key is rejected. This governs traffic that flows through the proxy — it does not, on its own, stop a compromised process from routing around the proxy (see the threat model below).
• Tamper-evident verdicts. A logged verdict has no UPDATE or DELETE path (the events table carries INSERT and SELECT policies only) and each row is hash-chained, so altering or deleting one after the fact is detectable rather than silent. This makes tampering evident, not impossible — a record that is never written cannot be altered later, but it can be lost (see Audit durability).

Threat model: Intercis enforces policy on every request that reaches it, regardless of what the agent asks for. Being in-path is a configuration setting, though: a fully compromised agent with environment access can repoint its API base URL and call the provider directly, exactly as it could skip an in-process SDK call. In-path tamper-resistance is real only when the proxy is paired with network egress control that prevents direct provider calls. Without that, Intercis governs the traffic that flows through it — not traffic a compromised process deliberately routes around it.

Infrastructure Hardening

Proxy — API Intercept

The Intercis proxy runs on Railway, in isolated containerized environments. Each deployment is:

• Deployed in isolated containers
• Runs as a single instance today (horizontal scaling is Phase 4)
• Automatically restarted on health check failure

Dashboard — SOC Interface

The Intercis dashboard runs on Vercel and provides audit visibility and policy management (enforcement happens in the proxy, not the dashboard):

• Edge-deployed globally for low-latency access
• DDoS mitigation at the edge (Vercel platform default)

Database — Supabase PostgreSQL

Event logs, policies, and audit trails live in Supabase PostgreSQL with Row Level Security enabled:

• Row Level Security (RLS): Policies enforce that users can only access their own organization's data, even if they compromise the API key.
• Encryption at rest and TLS in transit: Supabase and Railway platform defaults.
• Append-only event log: the events table carries INSERT and SELECT RLS policies only — no UPDATE or DELETE path — so a logged event cannot be altered or removed through the API.

Encryption in Transit

Security Headers & HTTP Policy

The Intercis marketing site returns the security headers below. The dashboard serves a broader policy to run its own scripts; both are in the repo (apps/site/vercel.json, apps/dashboard/vercel.json). The proxy is a JSON API: it returns the transport and frame headers (HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) but not a Content-Security-Policy.

Authentication & Access Control

Proxy API Authentication

Every governed request to the Intercis proxy must include the x-intercis-key header with a valid tenant API key:

• HMAC-SHA256 key validation with constant-time comparison to prevent timing attacks
• 256-bit CSPRNG key generation — keys are cryptographically random and per-tenant
• Keys are rotatable and revocable; revocation takes effect immediately
• Key usage is logged per-tenant for audit purposes
• Per-tenant rate limiting: sliding window limiter caps requests per minute per tenant and per agent. Auth failures are additionally limited per caller IP; in self-hosted deployments this requires declaring your edge proxy so the caller's address can be established (see the Enterprise deployment guide)
• Uniform 401 responses — no information leakage on failed auth

Dashboard Authentication

Dashboard access is authenticated via Supabase Auth (email/password and magic link):

• Cookie-based session management via @supabase/ssr — sessions are short-lived and refresh automatically
• JWT verification on every API route with explicit tenant_id enforcement (defense in depth)
• CSRF protection on all mutating requests via Origin header validation
• Role-based access: tenant owner vs. member roles enforced at the database level via RLS
• 12-character minimum password requirement, with a length check at signup
• SSO and MFA: on the roadmap — not yet available

Database Access Control

Supabase anon key is scoped and restricted via Row Level Security:

• Anon key can only INSERT into the design_partners table (for waitlist signups)
• All other tables require authenticated access with RLS policies
• No admin endpoints are publicly exposed
• Service role keys (for internal use) are never exposed to client-side code

Policy Engine & Detection

The Intercis policy engine enforces rules across multiple threat categories with a multi-layer detection strategy.

Pattern-Based Detection

The policy engine analyzes tool calls (function names, arguments, environment variable access) against regex patterns that detect:

• Credential exfiltration: Attempts to read AWS_SECRET_KEY, OPENAI_API_KEY, or similar
• Network exfiltration: curl/wget POST or upload, netcat, scp, and rsync to external hosts
• Supply chain attack: Malicious npm/pip/poetry installs and curl | bash / wget | sh pipe-to-shell
• Privilege escalation: Dangerous chmod (setuid) and chown to root
• Container escape: docker --privileged, docker run, nsenter, bind/cifs mount, and chroot
• Persistence: Cron job injection, SSH key placement, service registration
• Encoded execution: Base64, hex, or other obfuscation of suspicious commands
• Destructive shell commands: rm -rf and partition wipes (fdisk, format)
• Windows & PowerShell: Recursive force-deletes, shadow-copy and backup destruction, boot-recovery tampering, event-log clearing, security-tooling shutdown, credential dumping, encoded PowerShell, LOLBin remote execution
• Database attacks: DROP TABLE, TRUNCATE, bulk deletion, unauthorized schema changes
• Infrastructure sabotage: terraform destroy and kubectl delete

The pattern set is not built from hypothetical attacks. A subset of patterns carry OWASP agentic threat or MITRE ATT&CK technique identifiers — 16 annotations across the 110 patterns, not a per-pattern mapping — and the set was validated against the documented agentic threat landscape: destructive SQL against production databases, recursive file deletion by coding agents, and prompt-injected wiper commands among them. Windows/PowerShell patterns were verified blocking in Intercis's own production deployment (windows-lab tenant), July 2026 — 40 denials.

LLM-Based Intent Classifier

For execution-, file-mutating-, and MCP-tool calls that no deny-list pattern decides, an LLM-based intent classifier judges intent — it is not consulted for a call a pattern already blocked.

Only traffic on the LLM-API wire is visible. Hosted, server-side MCP tool calls (OpenAI mcp_call, mcp_list_tools, mcp_approval_request) never cross that wire and are not governed or logged today.

• Distinguishes a legitimate file operation from a destructive one on the call's own content
• Returns a one-word verdict — destructive or safe — nothing more
• Runs on a ~30-second budget and fails open (allows) if it is unavailable

Prompt Injection Scanner

Dedicated detection layer for prompt injection attacks:

• Instruction override: Attempts to replace or override the agent's original instructions
• Context extraction: Requests to reveal the system prompt or hidden instructions
• Role hijack: Attempts to reassign the model's role or identity (e.g. "enter admin mode")
• Delimiter escape: Attempts to break out of the prompt structure with fake system or assistant turns

Audit & Compliance

Event Log

Intercis maintains an append-only event log with no UPDATE or DELETE path, hash-chained so tampering is detectable:

• Every governed tool call is logged (best-effort): Timestamp, agent ID, tool name, arguments, verdict, and the policy that matched. Database writes never block the agent, so a failed allow or observe write is dropped rather than retried; deny records fall back to the spool described under Audit durability.
• Append-only by policy: The events table carries INSERT and SELECT Row Level Security policies only. There is no UPDATE or DELETE policy, so no tenant user, dashboard session, or compromised agent has a path to alter or remove a logged event.
• Outside the agent's reach: The log is written by the proxy, not by the agent, so once a record is written an agent has no path to alter or delete a record of its own blocked action — the property in-process enforcement cannot offer. A record can still fail to be written in the first place (see Audit durability); what an agent cannot do is tamper with one that was.
• Retention: Events are retained for the life of the tenant account; records are queryable from the dashboard and exportable to CSV from the event view. Each event is hash-chained — every row carries a SHA-256 event_hash computed over its own audit fields plus the previous row's hash, forming a per-tenant chain that makes after-the-fact tampering detectable. Configurable retention windows are on the roadmap and are not implemented today.

Audit durability

A silently dropped deny record would be a hole in the product's core artifact, so the proxy carries a best-effort outage buffer for deny records. We describe its limits plainly rather than call it a durable queue:

• Deny records only: when a write to the database fails, deny verdicts are appended to a local spool. allow and observe events are best-effort telemetry and are never spooled.
• Instance-local, not a queue: the spool is a JSONL file on the container's own disk (/tmp/intercis-event-spool.jsonl). It survives a transient database outage, not a container replacement — a buffer, not durable storage.
• Bounded: the spool is capped at 5 MB. Once full, the oldest line is evicted first; a single row larger than the cap is rejected outright rather than allowed to evict every other record.
• Drain on recovery: after the next successful write, up to 100 buffered rows are re-inserted, and the rest drain on later writes.
• Honest failure mode: the spool write can itself fail. When it does, that deny record is lost — we surface the gap rather than imply it cannot happen.
• Redaction before write: recognizable credential material in tool input is redacted before an event is persisted, on by default. Redaction is best-effort — if it throws, the proxy persists the event unredacted and logs the error rather than dropping the audit record, so redaction reduces credential exposure in the log but does not guarantee its absence.

Querying the event log

The append-only event log is queryable for incident investigation:

• Reconstruct the sequence of tool calls and policy verdicts for a given agent over a time window
• Each event carries timestamp, agent ID, tool name, arguments, verdict, and the policy that matched
• Query by agent, verdict, cloud provider, or time window from the dashboard

There is no session “replay” feature, and Intercis does not capture agent memory state or model temperature. The log is the record of what was attempted and what the proxy decided.

Validation Report

Intercis publishes a live validation report with evidence of the proxy's security controls in production:

• A comprehensive automated security test suite — deny-list, injection scanner, agent-identity, and Windows/PowerShell coverage — runs in CI on every push and PR to main (Railway and Vercel deploy independently)
• Caught 40 of 47 on our April 2026 agentic threat corpus (85.1%)
• Live smoke test results and latency benchmarks
• Reproduction instructions for independent verification

View the full validation report →

Certification status

Intercis is not SOC 2 certified. No audit is underway and no auditor is currently engaged. We would rather state that plainly than let a badge imply otherwise on a security product.

What does exist is the control set an audit would examine, documented on this page and verifiable today:

• Tenant isolation enforced at the database layer via Row Level Security
• Per-tenant API key authentication with HMAC-SHA256 validation, rotation, and immediate revocation
• Append-only event log — INSERT and SELECT Row Level Security policies only, no UPDATE or DELETE path
• Encryption in transit (TLS 1.2+, HSTS with the preload directive) and at rest (Supabase platform default)
• Role-based access control, CSRF protection, and a published security header policy
• A public validation report with reproduction instructions for independent verification

Certification is planned once revenue supports the cost of an audit. When that engagement begins we will name the auditor and the target window on this page. Until then, we will complete your vendor security questionnaire and walk your team through the controls above on request — security@intercis.io.

One distinction worth making explicit: Intercis does not generate SOC 2 or ISO 27001 evidence packages — no such export exists today. What Intercis does provide is the append-only, hash-chained event log described above: queryable, and exportable to CSV from the dashboard event view. That log can support your own audit work, but it is not a formatted compliance-evidence package, and we will never present it as one.

Responsible Disclosure

If you discover a security vulnerability in Intercis, please report it responsibly to:

Do not publicly disclose the vulnerability before we have had the opportunity to patch and release a fix.