Security

Intutic is a governance layer that sits between your AI agents and LLM providers. Security is foundational — every design decision prioritizes the principle that governance infrastructure must never become the attack surface it's meant to protect.

Threat Model

Intutic defends against three categories of threat:

Threat	Vector	Mitigation
Agent misuse	AI agent executes destructive tool calls (file deletion, credential exposure, unauthorized API calls)	Real-time SOP evaluation with BYPASS/ENHANCE/HIJACK/REASK/KILL verdicts via the circuit breaker
Credential leakage	API keys, tokens, or secrets exfiltrated through agent output or prompt injection	DLP scanning in the proxy hot path; secrets detected and redacted before reaching the LLM
Unauthorized access	Rogue agents or developers bypassing governance controls	Harness config drift detection with auto-revert, immutable local SOP rules, and local daily spend caps
Uncontrolled egress	An agent (or a compromised dependency it pulls in) reaches the network by a path other than the governing proxy, so nothing above ever inspects the traffic	Proxy-level allow-list enforcement (`intutic_settings.egress.mode`), and — closing the gap where an agent simply doesn't route through the proxy at all — `intutic enforce`'s host-level default-deny firewall. See Network Egress Control

Data Flow

Intutic runs in one of two modes, and they differ in one respect: whether anything is sent to Intutic.

Standalone (open-core default)

Developer → AI Agent → Intutic Proxy (:4000) → LLM Provider
               │            │
               │      ┌─────▼──────┐
               │      │  Policy    │
               │      │  Engine    │
               │      │  (WASM +   │
               │      │   SOPs)    │
               │      └─────┬──────┘
               ▼            │ decide: rules
         ┌───────────┐      ▼
         │ Hook gate │──▶ Decide engine (optional: your own
         │ (policy   │    model, on this machine or your network)
         │ snapshot) │
         └───────────┘
   (nothing is sent to Intutic; telemetry stays on this machine)

Every LLM request from an AI agent is routed through the local Intutic proxy on port 4000
The proxy evaluates tool calls against the SOPs' front matter and against WASM rules (sandboxed, with an enforced instruction budget and a wasmtime deadline)
Verdicts and telemetry stay on the local machine. Bandit routing state is written to your own Valkey, or to ~/.intutic/bandit-state.json when there is none; nothing is transmitted to Intutic or anyone else
Traces carry no prompts or completions — only structured telemetry (tool names, verdicts, token counts, timing). Two things the proxy keeps go further, and both are limited by default; see What the proxy keeps

This is what you get by default. Open core ships no control plane, and with policy.control_plane_url unset the policy pre-check is skipped entirely.

Data Locality

The proxy runs locally on the developer's machine. LLM traffic is never rerouted anywhere — it flows directly from the proxy to the LLM provider.

Standalone, nothing leaves the machine: no telemetry, no verdicts, no traces. Prompts and completions are never transmitted anywhere by the proxy.

Encryption

In Transit

All network communication is encrypted with TLS 1.2+:

Path	Protocol
Proxy → LLM Provider	HTTPS (TLS 1.2+)

At Rest

Data	Storage	Encryption
Session state & caches	Valkey (Redis-compatible)	None from Intutic. The `intutic-valkey` container `intutic start` runs keeps Valkey's default snapshots on disk, in its `/data` volume
Bandit learning (no Valkey)	`~/.intutic/bandit-state.json`	None — a plain JSON file with your default file permissions
Local config & credentials	`~/.intutic/credentials.json`	File permissions (`0600`) + system keychain; the hook gates refuse an agent tool call that names the file
Provider credentials in flight	Process memory only	Never written to disk

What the proxy keeps

Beyond the trace fields above, the proxy keeps two things that come from request content:

Replay contexts. A sampled 5% of requests (WASM_CONTEXT_SNAPSHOT_RATE) attach their rule-evaluation context to the trace, so a new rule can be replayed against real traffic. Each tool call in it carries its name and its arguments' top-level keys and size, not the argument values. A connected workspace can opt in to keeping the values with storeToolArguments; they are then kept with every secret and PII match redacted. Contexts a connected workspace stored before 2.5.1 are reduced to keys and sizes when its control plane upgrades.
The response cache, when a workspace or config turns it on (off by default; every cost posture turns exact matching on). An entry holds the prompt text and the answer for 24 hours. An exchange in which DLP finds a secret or personal data is never written to it.

Whatever the live PII detector actions, everything the proxy keeps is redacted for every PII detector, email and phone included, and for every secret pattern: replay contexts and the targets in a trace's change manifest (the commands, paths and URLs tool calls named). Live redaction of email and phone stays off by default because an agent editing a real address would write the placeholder back into the file. Change manifests a connected workspace stored before 2.6.0 have their targets withheld ([WITHHELD]) when its control plane upgrades; each entry keeps its tool, operation, kind, risk and size, and integrity roots sealed over those traces still verify (see Trace Integrity).

Enforcement Coverage

Connected harnesses get an enforcement tier from the governance layers found active in their config (see Compliance Scope):

Tier	Active layers
A	MCP proxy and a native hook gate: every tool call enforced in process
B	MCP proxy only
C	LLM proxy only
D	A rules file only: guidance the agent reads, checked after the fact
none	Nothing detected

Responsible Disclosure

If you discover a security vulnerability, please report it to support@intutic.ai. We aim to acknowledge reports within 24 hours and to patch critical and high-severity issues within 72 hours; see SECURITY.md.

Page	What it covers
Getting Started	Quickstart guide, local CLI setup, and harness connection
How It Works	Full architecture walkthrough — proxy, policy engine, control plane
Governance Controls Checklist	A control-by-control mapping against a standard enterprise evaluation checklist
Custom Filters (WASM)	WASM policy rules engine for custom tool-call filtering
CLI Reference	CLI commands, doctor diagnostic tool, and local configuration
Integrations Hub	Harness setup guides for 43 supported agent tools

Security ​

Threat Model ​

Data Flow ​

Standalone (open-core default) ​

Data Locality ​

Encryption ​

In Transit ​

At Rest ​

What the proxy keeps ​

Enforcement Coverage ​

Responsible Disclosure ​