Harness Security Matrix — Intutic Compliance Scope Open-Core
Last updated: Muse Code (20th), Grok Build (21st), dsh (22nd, developer preview), Xirp (23rd harness) onboarding + worktree propagation (TD-390), Agentic Orchestrator (24th harness), eve (25th harness, preview) onboarding complete, and a Wave A/B reconciliation pass adding AI SDK Harness (26th), AI SDK Workflow (27th), Strands Agents (28th, previously undocumented here), AWS Bedrock AgentCore Runtime/Gateway (30th), plus Anthropic Managed Agents (29th row — a server-side platform integration with no
HarnessType, included for governance-coverage completeness, not counted as a harness), and a row-count reconciliation pass appending the 10 remaining SDK-gated Python/TS frameworks from the Wave 1-2 platform-agents expansion that had aHarnessTypeand an/integrations/*page but no matrix row yet: LangChain (31st), CrewAI (32nd), AutoGen (33rd), AG2 (34th), Google ADK (35th), OpenAI Agents SDK (36th), Pydantic AI (37th), smolagents (38th), Mastra (39th), Vercel AI SDK (40th); plus TrueForge (41st harness, embedded-library deployment mode only — Phase 1 of a phased onboarding, see itsHarnessTypedoc comment for why the standalone/hosted server mode is a separate row), and TrueForge Server (42nd harness — Phase 2: TrueForge run as its own standalone/hosted server, governed by a new out-of-processservices/trueforge-bridge,GateKind: 'bridge', a fifth gate shape distinct from'hook'/'sdk'/'delegated'/'none')
Coverage: 41 active harnesses + 1 server-side platform integration (42 rows total)
This document is the canonical reference for what Intutic enforces, how, and the gaps that remain per harness.
Defense Vectors
| Vector | Mechanism | How it blocks | Scope |
|---|---|---|---|
| A — Client Hook | Pre-tool-use gate script; blocking contract varies by harness (exit code 2, {"cancel":true} on stdout, {"decision":"deny"} on stdout, a JS throw, a Python raise, or a Cordis waterfall {kind:'deny'} return) | Blocks before tool executes | The harnesses that write a generated on-disk hook file (as opposed to an SDK-side gate living in the developer's own process) — see the Hook (A) column of the Coverage Matrix below for the current, authoritative list rather than a count repeated here: currently Claude Code, Claude Desktop, Cursor, Windsurf, Cline, Roo Code, OpenClaw, OpenHands, Goose, Antigravity, Hermes, Pi, Codex CLI, Muse Code, Grok Build, GitHub Copilot (agent hooks, Preview), Continue CLI, n8n (workflow-level, manual install), and Open-WebUI (prompt-level filter). All of these enforce WHERE (argPattern) rules against the serialized tool input. Everything else with a Hook (A) ✅/⚠️ mark — LangGraph, dsh, the 10-framework SDK-gated family (LangChain, CrewAI, AutoGen, AG2, Google ADK, OpenAI Agents SDK, Pydantic AI, smolagents, Mastra, Vercel AI SDK), and TrueForge (embedded-library mode only) — gates in-process via intutic-clawde (Python) or @intutic/gate (TypeScript), not a generated file; dsh's plugin enforces the same argPattern rules via @intutic/gate's own Tier A1/A3. TrueForge's own veto surface is an async batch-approval responder rather than a synchronous per-call callback — see row 41. TrueForge Server (row 42) carries a DIFFERENT, weaker Hook (A) mark again — its gate runs in a wholly SEPARATE Intutic-operated process (services/trueforge-bridge) reacting to a pull-only event stream, not co-resident with or embedded in the harness's own process the way every other Hook (A) mark on this page is; see row 42's own note. Xirp and Agentic Orchestrator carry no gate of their own — they delegate entirely to whichever harness they wrap (GateKind: 'delegated'); for Agentic Orchestrator specifically, that delegation is only complete for its Claude Code/Codex backends — its third backend, OpenCode, has no gate to delegate to at all (see row 24 and TD-397) |
| B — Proxy Gate | LLM request inspection at the API boundary | Blocks / audits before LLM sees the prompt | 26 of the 41 active harnesses (+ Windsurf via TLS MITM); see matrix. Muse Code is env-var/launcher-only (no persistent base-URL setting confirmed), dsh redirects both its default route (llm-deepseek) and a kept selectable route (llm-pi-ai) (see TD-370), Xirp/Agentic Orchestrator have no LLM egress of their own, and eve/AI SDK Workflow/Strands Agents (default Bedrock provider)/Vercel AI SDK/TrueForge/TrueForge Server are each proxy-routable only in-code or only for a subset of providers — none of these ten are counted in this 26 |
| C — Drift Guard | File watcher + 30s poll cycle | Detects and restores tampered governance configs | 25 paths across all harnesses; every path is now also written into every discovered git worktree of a watched repo, not only the main checkout — see Worktree Coverage |
| D — Response Gate | Proxy-side inspection of the LLM response before it is forwarded to the client | Withholds a model-emitted tool_calls[] naming a denied tool before the client's tool runner sees it | Every harness whose LLM traffic traverses the proxy (Vector B scope); harness-agnostic, no client hook required |
Vector D — Response Gate
The response gate (response_gate.rs, open-core, default-on) is the product's only harness-agnostic pre-execution tool gate: because every response byte passes through the proxy before the client sees it, a denied tool call is refused before it ever reaches the harness's tool runner — no per-harness hook, no harness cooperation. It understands the Anthropic (tool_use blocks), OpenAI chat-completions (tool_calls[]), and OpenAI Responses (function_call output items) wire shapes, on both streaming and non-streaming paths. When a call is withheld, the agent receives an explicit in-band message that the call never ran, so it does not blindly retry.
It is fail-closed within a deliberate scope: the gate is inert unless the active role has a non-empty tool deny list; within that scope, a non-streaming body that will not parse as JSON is refused rather than forwarded (fail_closed, default true).
Known limits, stated precisely:
- Streams are gated on tool NAME only. OpenAI sends
function.nameon the first delta and dribbles the arguments out as JSON fragments across later chunks, so argument-level rules cannot be enforced mid-stream — argument-level matching is non-streaming-only. - Locally-originated tool calls are invisible to it. A tool call that never traverses the proxy (e.g. issued directly by a local plugin or harness-internal logic) cannot be seen or withheld; Vectors A and C cover that surface.
- Gemini's native
functionCallparts are not matched on either path; a request the proxy forwards to Gemini in its native shape is ungated by this vector.
Worktree Coverage
Every project-tier governance file this product writes (Vectors A and C — the client hook/config files themselves, and the drift guard that watches them) is untracked by convention: SOP content is synced from the control plane, not committed to the repo. A git worktree add-created checkout has its own independent working tree, so none of that untracked content existed in a worktree by default — writeConfigFiles/injectMcpServer running against only the ONE workspaceRoot a daemon instance was pointed at left every OTHER worktree of that same repo completely ungoverned, no matter what the main checkout had configured. This predates and is broader than any single harness — Xirp (row 22 below) is what surfaced it during this phase's research, because Xirp's whole model is spawning CLI agents each inside its own tmux session + git worktree, but the fix benefits any worktree-based workflow equally. See TD-390 for the full record.
The fix: services/sync-daemon/src/lib/gitWorktrees.ts's discoverWorktrees(repoRoot) runs git worktree list --porcelain every sync cycle (never cached across cycles) and the sync loop writes the same project-tier files into every discovered worktree, in addition to the main checkout. Locked worktrees are covered (locking only blocks git's own pruning, not ordinary file writes) and prunable worktrees (git has flagged the directory itself missing) are excluded, so this cannot resurrect a deleted worktree's folder. A worktree removed since the last cycle simply stops being returned by git worktree list — no stale-entry cleanup logic is needed for removal to work.
Agentic Orchestrator (row 24 below) uses the identical shape — one git worktree per feature, under ~/.agentic-orchestrator/worktrees/<feature>/<repo> — and required no changes to this mechanism at all: discoverWorktrees enumerates every worktree of a watched repo via git worktree list --porcelain, which does not care where under the filesystem a worktree lives. Confirmed by reading the project's own README, not merely assumed from the shape being similar to Xirp's.
Coverage Matrix
| # | Harness | Hook (A) | Proxy (B) | Drift Guard (C) | Self-Mod Risk | Notes |
|---|---|---|---|---|---|---|
| 1 | Claude Code | ✅ PreToolUse | ✅ | ✅ settings.json | Medium | Full coverage |
| 2 | Cursor Chat/Plan | ✅ 3-level hooks.json | ✅ | ✅ 3 paths | HIGH | Agent/Composer mode: see §Gaps |
| 3 | Windsurf | ✅ Shell/MCP hooks | ✅ TLS MITM | ✅ 2 paths | HIGH | Cascade traffic via TLS MITM proxy |
| 4 | Cline | ✅ .cline/hooks/ | ✅ VS Code settings | ✅ hooks.json | HIGH | Dual proxy injection |
| 5 | Roo Code | ✅ .intutic/hooks/roo-check.js | ✅ VS Code settings | ✅ .roorules | HIGH | Blocking hook — refuses via {"cancel":true} on stdout |
| 6 | Aider | ❌ No pre-edit hook | ✅ openai-api-base | ✅ .aider.conf.yml | HIGH | test-cmd/lint-cmd suppressed. The only native mechanism is the opt-in --git-commit-verify pre-commit hook — post-edit and blind to /run, so no gate is built on it |
| 7 | OpenHands | ✅ .openhands/hooks.json | ✅ llm.base_url | ✅ hooks.json | HIGH | Shell script hook, fail-closed |
| 8 | Codex CLI | ✅ codex-check.js | ✅ ~/.codex/config.toml | ✅ .env.intutic | Low | Blocking hook (exit 2) registered in ~/.codex/hooks.json + <repo>/.codex/hooks.json; WHERE argPattern rules enforced against the serialized tool input. Live-verified (codex-cli 0.147.0, 2026-08-10): a real codex exec session fired the hook, the unpinned kubectl apply was refused before execution with the rule named, and the pinned/benign commands ran |
| 9 | n8n | ⚠️ Workflow-level gate | ✅ API-configurable | ✅ gatekeeper node | Medium | n8n-governance-hook.js via EXTERNAL_HOOK_FILES (manual, deployment-side): workflow.preExecute receives the full Workflow and throws to abort — genuinely blocking, but per workflow, not per tool call. Node type ≈ tool name; argPattern matches the serialized node parameters. Live-verified (official n8n image, 2026-08-10): a running server with EXTERNAL_HOOK_FILES aborted the offending workflow (HTTP 500, error naming node and rule) and passed the clean one — after two live-only bugs were found and fixed (the real workflow.preExecute passes nodes as an object keyed by name, not the documented array; and the product snapshot's space-padded patterns cannot match dot-namespaced node types) |
| 10 | Continue | ⚠️ continue-check.js (CLI, interactive mode only) | ✅ apiBase in config.yaml | ✅ config.yaml | Low | Blocking hook (exit 2) in .continue/settings.json for the CLI (cn); the IDE extension has no hook system. The CLI also reads .claude/settings.json. Live-verified limits (cn 1.5.47): headless -p runs do not execute PreToolUse hooks at all — a headless cn is proxy-governed only — and cn's hook dispatcher fails open on hook errors by its own design. argPattern rules enforced when the hook runs |
| 11 | Goose | ✅ Plugin PreToolUse | ✅ provider.host | ✅ Immutable plugin | HIGH | chmod 444 + OS immutable flags |
| 12 | Antigravity | ✅ antigravity-check.sh | ✅ Proxy native | ✅ .gemini/settings.json | Medium | Blocking hook (exit 2); drift guard added |
| 13 | Claude Desktop | ✅ claude-desktop-check.js | ❌ Locked to Anthropic | ✅ claude_desktop_config.json | Medium | Blocking hook (exit 2); drift guard detects rogue MCP servers |
| 14 | Open-WebUI | ⚠️ Prompt-level filter | ✅ Docker env | N/A | Low | intutic-governance-filter.py can refuse (Python raise), but filters see a prompt, not a tool call — only snapshot rules marked block refuse; the compiled floor flags |
| 15 | OpenClaw | ✅ openclaw-check.js | ✅ | ✅ openclaw.json | Medium | Full coverage |
| 16 | Hermes | ✅ hermes-check.sh | ✅ | ✅ config.yaml | Medium | Binds tool execution hooks |
| 17 | Pi | ✅ pre-tool hooks | ❌ | ✅ hooks.json | Medium | Intercepts at workspace root |
| 18 | GitHub Copilot | ⚠️ Preview hooks | ❌ | ✅ copilot-instructions.md | Low | github-copilot-check.js (exit 2) via VS Code agent hooks (.github/hooks/*.json + ~/.copilot/hooks) — a Preview feature whose format may change; the gate refuses payloads it does not recognise, so a shift fails closed. Instructions file still merged. argPattern rules enforced. Contract re-verified 2026-08-10 against the live VS Code docs (envelope, exit-2, both file locations, chat.hookFilesLocations); an end-to-end block inside a Copilot-subscribed agent session remains unverified — it needs an interactive editor with an entitlement |
| 19 | LangGraph | ✅ SDK-side (Python raise) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | Gate lives in the developer's code via intutic_clawde.gate (guard_tools / @guard), not a generated hook file — it sees the tool call's full arguments, so argPattern rules apply; traces attributed via x-intutic-harness |
| 20 | Muse Code | ⚠️ muse-check.js | ⚠️ env-var only | ✅ 3 paths | Medium | Blocking hook (exit 2, ASSUMED contract — TD-362) registered in <repo>/.muse/hooks.json AND via the pre-approved managed_hooks_path tier (~/.config/muse/intutic-managed-hooks.json, referenced from ~/.config/muse/settings.json); covers both PreToolUse and PermissionRequest. No persistent proxy base-URL setting was confirmed — routing is META_API_KEY/launcher-flag only. The muse binary could not be installed to live-verify any of this (beta product, no public release channel found); see TD-362 |
| 21 | Grok Build | ✅ grok-check.js | ✅ config.toml [model.*] | ✅ .grok/hooks, config.toml, trusted_folders.toml | Medium | Blocking hook, PreToolUse with no matcher, registered in .grok/hooks/intutic-governance.json (project) and ~/.grok/hooks/intutic-governance.json (user). Confirmed blocking contract: {"decision":"deny","reason":"..."} on stdout, exit 0 — a different stdout shape from Cline/Roo Code's {"cancel":true}, so this harness carries its own stdout-decision-deny contract rather than reusing theirs. Double-gating note: Grok Build also natively reads .claude/settings.json and .cursor/hooks.json if present, so a workspace already running either of those gates fires BOTH on a Grok Build tool call — expected, additive, not a bug (see The gate backstop for the same "both layers firing is expected" posture applied to the proxy+gate combination). Not live-verified: Grok Build was not installable in the environment this harness was implemented in, so the per-file hook-registration schema (event/command/timeout fields) is this integration's own reasonable design against the confirmed facts, not a byte-for-byte match against a real install |
| 22 | dsh Preview | ⚠️ @intutic/gate/dsh (Cordis plugin) | ✅ llm-deepseek (default) + llm-pi-ai (selectable) | ✅ .dsh/profiles, .dsh/settings.yaml | Medium | DeepSeek's "dsh" (developer preview since 2026-08-13) is plugin-first (Cordis) — the gate is a real, checked-in TypeScript module (packages/gate-js/src/dsh.ts), not a generated shell/JS string. Registers on the confirmed tools/pre-execute Cordis waterfall event (@deepseek-ai/dsh-tools's shipped types), returning {kind:'deny', reason} to veto or calling next() to allow — genuinely novel among this matrix's contracts (waterfall-reject), not exit-code or stdout-JSON. Merge-written into EVERY existing $DSH_HOME/profiles/*/cordis.patch.yml (dsh has no single default profile — --profile <name> is required on every invocation). Known gaps (see TD-370): three of dsh's own packages (dsh-permission, dsh-settings-local, dsh-fs-policy) are npm-restricted and could not be inspected directly; the plugin registration still needs a manual dsh plugin --profile <name> add @intutic/gate (or pnpm install in the profile directory) before it actually loads — a fail-loud gap, not fail-open; and a machine where dsh has never been run has no profile to register into until the user's first dsh --profile <name> run. LLM egress now covers both llm-deepseek.baseURL (dsh's actual default route, per dsh-base's own agent-default-model row — confirmed against @deepseek-ai/dsh-llm-deepseek's shipped README) and llm-pi-ai.providers (a kept selectable route) — the earlier "selectable, not automatic" gap is closed |
| 23 | Xirp | ⚪ N/A — delegated | ⚪ N/A — delegated | ⚪ N/A — delegated | Low | NOT itself an AI agent — a macOS orchestrator that spawns Claude Code/Codex/Gemini CLI, each in its own tmux session + git worktree, preserving each wrapped harness's native, unmodified config (per Xirp's own FAQ). No gate/config of its own to register: a tool call inside a Xirp session is governed by whichever wrapped harness's own row above is already running. What IS this harness's own contribution: it is what surfaced the Worktree Coverage gap (TD-390) — before that fix, every wrapped harness's gate existed in the main checkout but not in the worktree the call actually ran in. Not live-verified: macOS-only beta with no installable artifact in this environment; detection paths (~/.xirp, Xirp.app) are this integration's own reasonable convention, not confirmed against a real install — see TD-391 |
| 24 | Agentic Orchestrator | ⚪ N/A — delegated | ⚪ N/A — delegated | ⚪ N/A — delegated | Low | NOT itself an AI agent — DoorDash's open-source (Apache-2.0, doordash-oss/agentic-orchestrator) desktop app + CLI (agentico) that spawns Claude Code/Codex/OpenCode, each in its own git worktree under ~/.agentic-orchestrator/worktrees/. No gate/config of its own to register: a tool call inside a session is governed by whichever wrapped backend's own row above is already running — except OpenCode, which has no row above to delegate to (no adapter/gate exists for it anywhere in this product), so an OpenCode-backed feature is genuinely ungoverned, not merely delegated. See TD-397. Live-verified, unlike Xirp: the real released binary (v0.152.0, darwin_arm64) was downloaded and run directly during this integration's research (--version, --help, server --help) — the wrapped-backend list, the --config/--state-dir defaults, and the worktree-per-feature model are all confirmed against the actual artifact and the project's own README, not merely this codebase's convention for comparable tools |
| 25 | eve Preview | ⚠️ @intutic/gate/eve (per-tool/connection approval policies) | ⚠️ direct-provider models only | ✅ .env.intutic | Medium | Vercel's filesystem-first durable-agent framework (npm eve, pre-1.0 preview) — the gate is a real, checked-in TypeScript module (packages/gate-js/src/eve.ts), not a generated script: intuticApproval() / intuticConnectionApproval() return AI SDK 7 approval statuses from eve's confirmed per-tool/per-connection approval policy surface ({type:'denied',reason} vetoes before execute() runs; verified against a pinned real install of eve@0.39.1, shipped .d.ts + runtime defineTool/defineMcpClientConnection/defineHook machinery). No agent-level default approval field exists (verified) — coverage is exactly the tools/connections the developer attaches the policy to, eve's own documented multi-tenant pattern. Observe-only intuticAuditHooks() maps eve's approval.candidate/approval.settled events onto tool_allowed/tool_blocked/tool_flagged (request-scoped: those events carry no tool name — TD-411). Proxy caveat: eve's default model routing is the Vercel AI Gateway, whose wire protocol the Intutic proxy does not parse — only in-code direct-provider models (withIntuticProxy(...)) are proxy-governed; no env-var base-URL override exists (TD-412). Detection is a compound check (eve dep + agent/ directory). Preview churn shield per the dsh precedent — TD-410. Not live-run-verified: no end-to-end eve dev session was exercised (TD-411) |
| 26 | AI SDK Harness | ⚠️ @intutic/gate/harness approval-flow responder + intuticSandboxBootstrap() (Tier A1 only) | ❌ N/A — sandbox traffic never crosses the local proxy | ✅ .env.intutic | Low | Vercel's @ai-sdk/harness HarnessAgent runtime — tools execute server-side inside a Vercel Sandbox microVM, not on the machine running Intutic. Custom host-executed tools get a real per-call gate via intuticStaticApprovals() + intuticApprovalResponder() (every custom tool marked 'user-approval', each pause answered with a real Gate.guard() verdict). recommendedHarnessSettings() now defaults to inactiveTools: ['bash'], removing bash from the tool set entirely (confirmed via real shipped dist/index.js, not just types) — a stronger mitigation than approval-gating since the tool is never callable; opt out with filterBash: false. Other built-in sandbox tools (read/write/edit/glob/grep) remain governed only by the coarse permissionMode setting — defaults to 'allow-all', no per-call approval surface at any mode. intuticSandboxBootstrap() additionally injects a Tier A1 policy-snapshot hook + .claude/settings.json directly into the sandbox filesystem via sandboxConfig.onBootstrap — a real but strict subset of a laptop gate (no SOP tier, review-hold, or event draining), Claude Code only; its bootstrap-channel mechanics were live-verified against a real Vercel Sandbox (files land, hook genuinely blocks/allows), while the bridge integration, snapshot/resume survival, and the Grok Build path remain unverified pending credentials — see TD-417. Sandbox network egress is governed by the sandbox's own networkPolicy (host/CIDR allow-deny), not Intutic DLP — that traffic never reaches the local proxy at all. Self-Mod Risk is Low precisely because tool execution happens off-host, in a microVM the local config-drift guard cannot reach either way. Detection is @ai-sdk/harness, any @ai-sdk/harness-*, or any @ai-sdk/sandbox-* in package.json. See the integration page |
| 27 | AI SDK Workflow | ✅ @intutic/gate/workflow's withIntuticApproval() (per-tool needsApproval) | ⚠️ in-code only, same limitation as Vercel AI SDK | ✅ .env.intutic | Medium | Vercel's @ai-sdk/workflow WorkflowAgent on the Workflow DevKit. The veto surface is per-tool needsApproval — the agent itself carries no approval option — and a gated call pauses durably, potentially resuming hours later. The durable runtime retries thrown errors by default, so a plain denial would be replayed to max attempts; this adapter's refusals carry error.name === 'FatalError' (matching FatalError.is()) so the runtime aborts instead of retrying. LLM-egress routing is in-code only via withIntuticProxy() — same limitation as the Vercel AI SDK row — and is off the path entirely when the workflow is deployed to run on Vercel's own infrastructure rather than the developer's machine. Detection requires @ai-sdk/workflow in package.json (the unscoped workflow package alone is not a trigger). See the integration page |
| 28 | Strands Agents | ✅ SDK-side (intutic_clawde.gate.adapters.strands, BeforeToolCallEvent.cancel_tool — MCP tools included) | ⚠️ Anthropic/OpenAI/LiteLLM providers only | ✅ .env.intutic | Medium | AWS's open-source agent framework (Bedrock AgentCore's default framework). The SDK tool gate is the enforcement point regardless of LLM provider. Strands' default provider, BedrockModel, calls Bedrock SigV4-signed — the Intutic proxy cannot re-sign SigV4 requests, so no base-URL env var can route it through the proxy (same for the SageMaker provider); this is the first framework in the SDK-gated family whose default egress is unroutable. Anthropic/OpenAI/LiteLLM providers remain proxy-routable via .env.intutic's base-URL vars. Detection is strands-agents in a Python manifest. See TD-420 and the integration page |
| 29 | Anthropic Managed Agents | ✅ SDK-side session-confirmation responder (IntuticSessionConfirmer, TS + Python) | ⚪ N/A — Anthropic hosts the session; no local LLM egress to route | ⚪ N/A — no local config file, no HarnessType, not detected by intutic init/intutic connect | Low | Architecturally unlike every other row in this table: the customer's process does not run the tool-call loop — Anthropic hosts a "session" that emits an event stream and the customer's backend answers it. agent.tool_use/agent.mcp_tool_use calls the server evaluated to evaluated_permission: "ask" (e.g. permission_policy: always_ask) pause the whole session until the backend sends user.tool_confirmation; IntuticSessionConfirmer answers that pause with a real Gate.guard() verdict — a genuine pre-execution veto, not audit-only. agent.custom_tool_use (the customer's own tools) has no pause concept and is gated separately via wrapManagedAgentsCustomTool(s) (TS) / @guard before @beta_tool (Python). A tool configured always_allow is an architectural ceiling, not a bug — the call never reaches the backend as an event to answer at all (TD-425). Listed here for governance-coverage completeness even though it carries no HarnessType — see the warning on its own integration page for why auto-detection was deliberately not built |
| 30 | AWS Bedrock AgentCore | ⚪ Runtime: N/A — delegated to whichever framework adapter the hosted code uses. Gateway: tools/agentcore-interceptor Lambda | ❌ Bedrock's own model-invocation traffic (Converse/InvokeModel) is SigV4-signed, not proxyable | ⚪ N/A — Runtime's writeConfig is a no-op (HarnessType: agentcore-runtime exists so intutic status/intutic init can report the deployment target) | Low | Two structurally different integrations under one row, per the integration page: Runtime hosts the customer's own agent code (any framework) unchanged — governance is whichever already-supported framework SDK gate that code uses (Strands, LangGraph, CrewAI, ...), same as anywhere else that framework runs; if the Runtime-hosted code uses no framework this registry supports (raw boto3), coverage is genuinely zero, the same honest gap Agentic Orchestrator's OpenCode backend has. Gateway is a deployed AWS resource, not something on a developer's laptop — like QM, it has no HarnessType and is never detected by intutic init; its coverage is the tools/agentcore-interceptor Lambda, attached as a REQUEST interceptor, calling POST /api/v1/integrations/agentcore/gateway-check. Bedrock's own model-invocation traffic is SigV4-signed and cannot be transparently redirected through the Intutic proxy on either shape. |
| 31 | LangChain | ✅ SDK-side (intutic_clawde.gate.adapters.langchain.IntuticMiddleware, LangChain v1.x AgentMiddleware.wrap_tool_call) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | LangChain v1.x's documented wrap_tool_call(request, handler) veto point; on deny, IntuticMiddleware returns a ToolMessage(status="error") without calling handler — the tool body never runs. Pre-1.0 LangChain, or plain tool objects: the framework-agnostic guard_tools() helper duck-types .func/._run without importing langchain. Detection also covers LangChain.js (langchain npm) for reporting purposes only — this adapter's env-writer and SDK gate are Python-only, matching intutic_clawde.gate.adapters.langchain; a JS/TS tool-call gate for LangChain.js does not exist yet. See the integration page |
| 32 | CrewAI | ✅ SDK-side (intutic_clawde.gate.adapters.crewai.install, CrewAI's global before_tool_call hook registry) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | CrewAI (v1.15.3+) documents a before_tool_call hook returning False to block, True/None to allow. Because CrewAI's own dispatcher swallows any hook exception that is not its internal abort signal and treats the call as allowed, this adapter deliberately returns False on any exception (not only a confirmed IntuticGateRefusal) — a fail-closed posture proven necessary by driving a real crewai==1.15.16 install. Known transitive vulnerabilities (2026-08-19, updated 2026-08-30): crewai pins chromadb>=1.1.0,<1.2.0, which carries four unpatched CVEs — CVE-2026-45829, CVE-2026-45833 (both critical, code injection), CVE-2026-45830, CVE-2026-45831 (both high, cross-tenant access-control gaps) — relevant only if you separately run a ChromaDB server reachable from an untrusted network; this integration never starts one. See TD-395, TD-461 and the integration page |
| 33 | AutoGen | ⚠️ SDK-side (intutic_clawde.gate.adapters.autogen.IntuticInterventionHandler, InterventionHandler.on_send — runtime-routed FunctionCall messages only) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | Structurally blind to the common case. on_send is the only confirmed veto point Microsoft AutoGen (autogen-core/autogen-agentchat/autogen-ext, 0.4+) publishes for a FunctionCall, but it only fires for messages explicitly routed through AgentRuntime.send_message/publish_message. AssistantAgent — the class essentially every AutoGen application and tutorial is built on — dispatches tool calls directly via workbench.call_tool_stream(...)/handoff_tool.run_json(...), entirely in-process, bypassing the handler completely; confirmed by reading autogen_agentchat.agents._assistant_agent directly, not inferred. Mitigation: wrap tool objects with guard_tools()/@guard before constructing the AssistantAgent's toolset — IntuticInterventionHandler only adds coverage for custom AgentRuntime/RoutedAgent systems dispatching FunctionCall messages by hand. autogen_core.ToolException does not exist at autogen-core==0.7.5 — DropMessage is the only confirmed veto. See TD-374 and the integration page |
| 34 | AG2 | ✅ SDK-side (intutic_clawde.gate.adapters.ag2.IntuticMiddleware, BaseMiddleware.on_tool_execution) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | AG2 (ag2==1.0.2+) is a from-scratch fork/continuation of pre-Microsoft AutoGen with no shared API surface — a different framework from row 33 above, despite the name; do not confuse the two. BaseMiddleware.on_tool_execution(call_next, event, context) is AG2's own documented veto point, confirmed by reading ag2/middleware/base.py, ag2/tools/executor.py, and ag2/tools/final/function_tool.py against a real install; on deny it returns ToolErrorEvent.from_call(...) without calling call_next. Detection uses a boundary-aware regex (not a plain substring) to avoid false-positiving on strings like "flag2". Open question (TD-376): the fail-closed-on-any-exception posture inside on_tool_execution was carried over from CrewAI's proven-necessary precedent, but AG2's own event/stream dispatcher's behavior on an exception escaping the hook was not independently confirmed live. See the integration page |
| 35 | Google ADK | ✅ SDK-side (intutic_clawde.gate.adapters.google_adk.IntuticPlugin, ADK's before_tool_callback) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | ADK documents before_tool_callback — returning a non-None dict skips the real tool call and that dict becomes the synthetic result. Both of ADK's registration surfaces are covered: IntuticPlugin (global, via App(plugins=[...]), every tool call across the app) and intutic_before_tool_callback (per-agent fallback for callers not using App(plugins=[...]), LlmAgent(before_tool_callback=...)) — the two use different keyword conventions on ADK's own call sites (tool_args= vs args=) and both adapter functions match theirs exactly. On deny, both return a synthetic {"status": "error", "error": "[Intutic Governance] BLOCKED: ...", ...} dict instead of letting the tool run. See the integration page |
| 36 | OpenAI Agents SDK | ⚠️ SDK-side, both ecosystems (Python: intutic_clawde.gate.adapters.openai_agents.intutic_tool_guardrail; TS: @intutic/gate/openai) | ✅ OPENAI_BASE_URL (zero-code — both ecosystems' underlying openai client reads it automatically) | ✅ .env.intutic | Medium | Covers both the Python (openai-agents) and TypeScript (@openai/agents) ecosystems — Python's documented @tool_input_guardrail (intutic_tool_guardrail, attached via function_tool(tool_input_guardrails=[...])) and TypeScript's @intutic/gate/openai (wrapAgent()/intuticToolGuardrail(), verified against @openai/agents@0.16.1); on deny both hand a [Intutic Governance] BLOCKED: ... message back to the model in place of a tool result. Structural gap: hosted/server-side tools (webSearchTool, fileSearchTool, codeInterpreterTool, image generation, hosted-environment shellTool) execute at OpenAI and are "not gateable client-side, by anyone" — no guardrail, approval hook, or wrapper ever sees them. computerTool's only hook is a coarse needsApproval predicate (no refusal message; an approving handler overrides the gate). An unwrapped hostedMcpTool defaults to require_approval: 'never' — entirely ungated until wrapped via wrapAgent. Separately: @openai/agents ships tracing on by default, whose exporter POSTs tool inputs/outputs to a hardcoded api.openai.com endpoint that ignores OPENAI_BASE_URL; installOpenAiGate() disables it by default (OPENAI_AGENTS_DISABLE_TRACING=1). See the integration page |
| 37 | Pydantic AI | ⚠️ SDK-side (intutic_clawde.gate.adapters.pydantic_ai.guard_agent/IntuticWrapperToolset, WrapperToolset.call_tool override) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | IntuticWrapperToolset subclasses Pydantic AI's own WrapperToolset (built for exactly this intercept-before-delegating shape); on deny it raises ModelRetry(...), confirmed by reading pydantic_ai/tool_manager.py — the model sees the refusal in place of a tool result and the wrapped toolset's call_tool never runs. Coverage gap: guard_agent wraps Agent(toolsets=[...]) entries (_user_toolsets/_dynamic_toolsets) but deliberately leaves agent._function_toolset — the toolset backing the commonly-used @agent.tool decorator / Agent(tools=[...]) — untouched; those need @guard or an explicit FunctionToolset(tools=guard_tools([...])) to be covered. guard_agent also reaches into private attributes (confirmed present at pydantic-ai-slim==2.31.1) with no public replacement point — a future release could silently turn it into a no-op. See the integration page |
| 38 | smolagents | ⚠️ SDK-side, split by agent class (guard_tools/@guard for ToolCallingAgent; intutic_clawde.gate.adapters.smolagents.IntuticPythonExecutor for CodeAgent) | ✅ base_url / intutic exec | ✅ .env.intutic | Medium | ToolCallingAgent's discrete tools are gated exactly like every other framework (guard_tools, extended to duck-type smolagents' .forward so .name/.inputs schema survives). CodeAgent is structurally different: a "tool call" is a whole chunk of model-generated Python handed to a PythonExecutor, so IntuticPythonExecutor gates the generated code string ({"command": code_action}) before execution, raising smolagents.local_python_executor.InterpreterError on deny — driven live against smolagents==1.26.0. This closes real coverage CodeAgent had none of before, but is narrower than argument-level gating: runtime-constructed strings evade argPattern, conditional/unreached branches are judged the same as always-taken ones, and tools invoked by the running code via send_tools are a real in-process call invisible to this pre-execution text check. No finer-grained veto point exists in smolagents to close this. See TD-377 and the integration page |
| 39 | Mastra | ⚠️ SDK-side (@intutic/gate/mastra's intuticHooks(), Agent.hooks.beforeToolCall) | ✅ baseURL (in-code provider construction) | ✅ .env.intutic | Medium | beforeToolCall returns { proceed: false, output } on deny — Mastra skips the tool's real execute entirely, for both natively-defined and MCP-sourced (@mastra/mcp) tools alike (both merge into the same tool record before hooks wrap it); verified against @mastra/core@1.59.0. Known bypass (TD-380), Mastra's own documented behavior, not an Intutic defect: if any caller of .generate()/.stream() passes its own call-level hooks option — even {} — Mastra replaces the agent-level hooks wholesale rather than merging, silently disabling this gate for that call with no error or warning; callers that pass call-level hooks must compose intuticHooks().beforeToolCall into them explicitly. See the integration page |
| 40 | Vercel AI SDK | ✅ SDK-side (@intutic/gate/vercel's intuticToolApproval(), the ai package's toolApproval option) | ⚠️ in-code only — no environment-variable LLM routing exists for this framework | ✅ .env.intutic | Medium | toolApproval (accepted by generateText, streamText, ToolLoopAgent) is the ai package's (v6+) documented pre-execution veto point; on deny it resolves { type: 'denied', reason } and the tool's real implementation never runs, on allow it resolves 'not-applicable', composing cleanly with any other approval mechanism (e.g. a human-in-the-loop 'user-approval' status) or with Vercel's own first-party @ai-sdk/policy-opa Rego-backed adapter. Unlike almost every other harness in this catalog, LLM egress cannot be routed via env var: providers (@ai-sdk/openai, etc.) are constructed directly in code, so .env.intutic's base-URL vars are written but inert unless every provider-construction call site uses withIntuticProxy() explicitly. See the integration page |
| 41 | TrueForge Embedded only | ⚠️ SDK-side, ASYNC BATCH responder (@intutic/gate/trueforge's intuticApprovalResponder(), TrueForge's tool.approval_required/user.tool_approval turn contract) — see the note below distinguishing this from a synchronous per-call callback | ⚠️ in-code only — VercelAIProviderConfig.baseUrl, no environment-variable LLM routing | ✅ .env.intutic | Medium | TrueFoundry's open-source agent-runtime library (github.com/truefoundry/trueforge, MIT), embedded via @truefoundry/trueforge-core directly into another team's Node process — this row covers ONLY that embedded-library deployment mode. Confirmed against a real install (@truefoundry/trueforge-core@0.1.4, shipped .d.ts files read directly, not assumed): there is NO synchronous in-process approval callback anywhere in the package, unlike Mastra's beforeToolCall or the Vercel AI SDK's toolApproval — every .d.ts was grepped for approvalResolver/onApproval/approvalHandler/resolveApproval with zero matches, and ITurnResourceResolver (the surface this integration's authoring plan specifically pointed at) carries no tool-call veto hook at all. The ONLY approval mechanism, embedded or not, is the same async turn/event contract TrueForge's standalone server exposes over HTTP: a turn pauses on a tool.approval_required required action naming the pending call only by {id, source_event_id} (no tool name or arguments travel on the event), and answering it means starting a NEW turn carrying a user.tool_approval input item. intuticApprovalResponder() evaluates a batch of already-resolved pending requests through Gate.guard() and produces those items — but resolving source_event_id back to a real tool name and arguments, and driving the turn/event loop itself, is necessarily the embedding host's own hand-written code, not something this adapter configures or verifies. This Hook (A) mark is deliberately distinct from the plain ✅/⚠️ this catalog uses for a synchronous SDK callback (Mastra, Vercel AI SDK, AI SDK Harness's continuation-based responder is the closer precedent) — it is real, pre-execution, fail-closed coverage, but only for the portion of the orchestration loop the embedding host actually wires up correctly. TrueForge run as its own standalone/hosted server is explicitly NOT covered by this row — nobody embeds an Intutic gate into a third-party OSS server process; that deployment mode needs an external Intutic-operated bridge service, which is HarnessType.TRUEFORGE_SERVER, row 42 below. Also not covered: TrueForge's own require_approval_for_tools MCP tool-selector policy (@all/@write/@destructive/a specific tool) controls which tool calls even emit a tool.approval_required pause in the first place — an operator who leaves it narrow gets tool calls that never pause and that this gate never sees, TrueForge's own default-scoped design, not an Intutic gap, but a real coverage-scoping factor. See the integration page |
| 42 | TrueForge Server Standalone/hosted | 🌉 OUT-OF-PROCESS bridge (services/trueforge-bridge, GateKind: 'bridge') reacting to the same tool.approval_required/user.tool_approval turn contract row 41 documents — see the note below for why this mark is deliberately NOT the same ✅/⚠️ shape as row 41's or any other Hook (A) mark on this page | ⚠️ in-code only — PUT /api/v1/settings/model-providers, no environment-variable LLM routing | ⚪ N/A — no config file exists to drift-guard (not detected by intutic init; see Notes) | Medium | TrueForge (github.com/truefoundry/trueforge, MIT) run as its OWN standalone or hosted server — npx @truefoundry/trueforge, its Docker Compose stack, or its Helm chart — rather than embedded into another team's process (row 41). Not detected by intutic init's repo scan at all: this is an operator-configured deployment, not a package.json dependency of whatever repo the CLI happens to run against, so there is no writeConfig step and no on-disk file for the Drift Guard (C) column to watch. This Hook (A) mark is deliberately a different symbol, not a reused ✅/⚠️, stated plainly rather than left implicit: every OTHER Hook (A) mark in this catalog — including row 41's own SDK-side async responder — runs co-resident with or embedded in the governed harness's own process. This one does not. services/trueforge-bridge is a wholly SEPARATE Intutic-operated process, reacting to a PULL-ONLY event stream (SSE subscribe, or event-list polling as a fallback — there is no webhook; TrueForge never pushes anything to an external system) rather than running inside the harness at all. That is a strictly weaker trust boundary than anything else on this page carries a Hook (A) ✅/⚠️ for: a bridge that is down, disconnected, or slow to reconnect misses pauses for that window, in a way no in-process gate can. When connected and reacting, the check itself is real: SOP argPattern rules (packages/gate-js's soprules.ts, reused directly) then POST /api/v1/hook-gate, fail-closed on any transport/parse error, identical governance logic to every other JS/TS-native row on this page. The same require_approval_for_tools/MCP-selector caveat row 41 documents applies here too, and matters MORE: row 41's embedding host at least controls its own approval-loop wiring; here there is no embedding host at all, only whatever selector each MCP server on the operator's TrueForge instance happens to be configured with — a narrow/default selector means some tool calls never pause and are invisible to the bridge, full stop. See the integration page |
Per-Harness Onboarding Guide
Claude Code
intutic connect --harness claude-codeWrites .claude/settings.json + ~/.claude/settings.json with permissions.deny rules and PreToolUse hooks. Hook script at .intutic/hooks/claude-code-check.js. Drift guard watches both paths.
Cursor
intutic connect --harness cursorWrites .cursorrules (governance text) + .cursor/hooks.json (project) + ~/.cursor/hooks.json (user).
Windsurf
intutic connect --harness windsurfWrites .windsurfrules + ~/.codeium/windsurf/hooks.json + .windsurf/hooks.json. Also configures ~/.codeium/windsurf/settings.json with http.proxy pointing to the Intutic TLS MITM proxy (port 8877). Cascade AI traffic is governed via the proxy.
Important: The Intutic CA cert must be trusted for TLS MITM to work:
bashintutic init # Generates CA cert and injects into user trust store
Cline
intutic connect --harness clineWrites .clinerules (governance text) + .cline/hooks/hooks.json (blocking PreToolUse hook). Also injects cline.apiBase and cline.openAiBaseUrl into VS Code settings + ~/.intutic/.env.intutic sidecar.
Aider
intutic connect --harness aiderWrites .aider.conf.yml with openai-api-base and anthropic-api-base set to the Intutic proxy. Strips test-cmd and lint-cmd if present (these are auto-executed on startup and represent the highest Aider privilege escalation risk). Strip events are logged to the control plane audit feed.
OpenHands
intutic connect --harness openhandsWrites config.toml with [llm] base_url and [intutic] SOP section. Also writes .openhands/hooks.json with PreToolUse shell hook (fail-closed).
Goose
intutic connect --harness gooseWrites ~/.agents/plugins/intutic-governance/hooks/hooks.json + scripts/intutic-check.sh. Applies chmod 444 + chflags uchg (macOS) or chattr +i (Linux) to make plugin files immutable. Also merges provider.host into ~/.config/goose/config.yaml.
Muse Code
intutic connect --harness muse-codeWrites AGENTS.md (governance text — Muse falls back to CLAUDE.md if this is absent) and installs the PreToolUse/PermissionRequest gate at two tiers: <repo>/.muse/hooks.json (project) and the pre-approved managed_hooks_path tier — an Intutic-owned ~/.config/muse/intutic-managed-hooks.json, referenced by a narrow merge into ~/.config/muse/settings.json (schema_version and any other key you have set are preserved). MCP servers declared under mcp_servers in settings.json (both stdio and streamable_http) are proxy-wrapped the same way every other JSON-map harness's servers are. Skills under ~/.agents/skills are already covered by the product's existing skill-scanning feature — nothing harness-specific was needed there. The muse binary could not be installed to live-verify the block/deny wire contract, the hooks.json schema, or the managed_hooks_path semantics — see TD-362.
Grok Build
intutic connect --harness grokWrites AGENTS.md (governance text) + .grok/hooks/intutic-governance.json (project) + ~/.grok/hooks/intutic-governance.json (user) — a blocking PreToolUse hook with no matcher. Also merges base_url into every existing [model.*] table in config.toml at both project and user level (XAI_API_KEY remains the auth mechanism; only the endpoint is redirected). MCP servers declared under [mcp_servers.*] in either config.toml are proxy-wrapped the same way every other harness's mcpServers map is.
Double-gating: Grok Build also natively executes
.claude/settings.jsonand.cursor/hooks.jsonhooks if either is present in the workspace — so a project already connected to Claude Code or Cursor may already be partially governed under Grok Build before runningintutic connect --harness grokat all. Connecting Grok Build natively adds its own gate on top; both firing on the same blocked call is expected (see the coverage matrix row above).
dsh Preview
intutic connect --harness dshMerge-writes an intutic-governance plugin row into every EXISTING $DSH_HOME/profiles/*/cordis.patch.yml, declares @intutic/gate in that profile's package.json dependencies, and merges proxy routes into settings.yaml's llm-deepseek.baseURL (dsh's default LLM route) and llm-pi-ai.providers (a kept selectable route). See the dsh integration guide for the manual pnpm install/dsh plugin add step this harness still needs before the gate actually loads, and TD-370 for what remains unconfirmed against DeepSeek's own npm-restricted packages.
Xirp
intutic connect # no --harness xirp step — see belowWrites nothing for Xirp itself. Connect the wrapped harness you actually use (Claude Code, Codex, …) against the main checkout of the repository Xirp will manage; the sync daemon's worktree coverage then propagates that harness's own gate/config into every git worktree Xirp spins up from there, automatically, every sync cycle. See apps/docs/integrations/xirp.md for the full detection/governance model and TD-390/TD-391 for what remains unconfirmed.
Agentic Orchestrator
intutic connect # no --harness agentic-orchestrator step — see belowWrites nothing for Agentic Orchestrator itself. Connect Claude Code and/or Codex (the two backends this product can actually gate — not OpenCode, see Known Architectural Gaps below) against the main checkout of the repository Agentic Orchestrator will manage; worktree coverage then propagates that backend's own gate/config into every git worktree Agentic Orchestrator spins up from there, automatically, every sync cycle — no new code was required for this, the same general mechanism Xirp's phase built already covers it. See apps/docs/integrations/agentic-orchestrator.md for the full detection/governance model and TD-397 for the OpenCode gap.
eve Preview
intutic connect --harness eveWrites .env.intutic (proxy vars + a pointer at the SDK-side gate). The blocking gate itself is @intutic/gate/eve — intuticApproval() / intuticConnectionApproval() attached as approval policies on the tools and connections in your agent/ directory (eve has no agent-level default approval field), plus the observe-only intuticAuditHooks() for eve's human-approval lifecycle. eve's default AI Gateway model routing is not proxy-governable; only in-code direct-provider models via withIntuticProxy(...) are. See the eve integration guide and TD-410/TD-411/TD-412.
Known Architectural Gaps (Permanent)
| Harness | Gap | Reason | Mitigation |
|---|---|---|---|
| Cursor Agent/Composer | No hook/proxy interception | Proprietary Cursor backend, hardcoded | Document-only: recommend Chat/Plan panel for governed workflows |
| Claude Desktop | No LLM proxy interception | Locked to Anthropic; no base-URL override | Blocking pre-tool hook (claude-desktop-check.js, exit 2) + drift guard watches config for rogue MCP servers |
| Windsurf Cascade AI | Cannot intercept without TLS MITM | No base URL field | TLS MITM via local CA (see windsurf-tls-mitm.md) |
| n8n granularity & install | Workflow-level, manual install | EXTERNAL_HOOK_FILES is read by the n8n server process at startup — the daemon cannot set another process's environment, and workflow.preExecute gates whole executions, not individual tool calls | n8n-governance-hook.js + INSTALL.md generated every sync; one offending node aborts the execution with an error naming the node and rule |
| GitHub Copilot hook stability | Agent hooks are Preview | The .github/hooks/*.json format may change between VS Code releases | The gate refuses stdin payloads it does not recognise (fail closed); instructions file remains as a fallback layer |
| Muse Code proxy routing | No persistent proxy base-URL setting confirmed in settings.json | Muse exposes a --base-url CLI flag and a META_API_KEY env var, but no equivalent persistent config key could be confirmed from available docs/source (beta product) | Document-only for now: route via the launcher flag or env var; the client hook (PreToolUse/PermissionRequest, both tiers) remains the primary enforcement surface regardless of egress routing |
| Agentic Orchestrator's OpenCode backend | No gate exists to delegate to | OpenCode is one of Agentic Orchestrator's three wrapped CLI backends (confirmed via agentico server --help), but OpenCode itself has no Intutic adapter or gate anywhere in this product — unlike the Claude Code/Codex backends, which are fully gated | Document-only: restrict agentico server --providers claude,codex to avoid running features against the ungoverned backend, until OpenCode itself gets an Intutic integration. See TD-397 |
| Strands Agents' default (Bedrock) LLM egress | No proxy interception (Vectors B and D) for SigV4-signed providers | Strands Agents defaults to BedrockModel — boto3 calls SigV4-signed against bedrock-runtime.<region>.amazonaws.com. The Intutic proxy does not speak Bedrock's wire protocol and cannot re-sign SigV4 requests, so no base-URL env var can route this traffic through it (same applies to Strands' SageMaker provider). First framework in the SDK-gated family whose DEFAULT egress is unroutable | The SDK tool gate (intutic_clawde.gate.adapters.strands, BeforeToolCallEvent.cancel_tool — MCP tools included) is the enforcement point regardless of provider; Anthropic/OpenAI/LiteLLM providers remain proxy-routable via .env.intutic's base-URL vars. See TD-420 and the integration page |
Known Non-Integratable Platforms
Internal-only or otherwise closed AI agent platforms this product cannot integrate with today, because no public artifact exists for Intutic to detect, gate, or route traffic through — not a decision to skip them, a hard blocker. Listed here (rather than silently omitted) so an audit does not mistake absence for an oversight, and re-checked periodically for a public release. Distinct from Known Architectural Gaps above, which covers harnesses this product DOES integrate with but cannot fully cover — these rows cover harnesses with zero integration surface, full stop.
| Platform | Why it can't be integrated | Evidence | Monitoring |
|---|---|---|---|
| DoorDash Flux | Real product, confirmed to exist — but internal-only by design, not merely undiscovered. DoorDash's own engineering blog and a DoorDash executive's own public statement both describe it explicitly as an internal cloud-based agents platform (background coding/review/triage agents in isolated sandboxes, triggered from Slack/GitHub/CLI, governed via an internal MCP gateway) — there is no installable client, no config file, no binary, and no API surface exposed outside DoorDash's own infrastructure for Intutic to detect or gate | careersatdoordash.com engineering blog describes Flux as DoorDash's internal cloud-based agents platform; a DoorDash co-founder's own public post calls it "Our internal platform Flux"; no doordash-oss (or any other public DoorDash) GitHub repo, npm/PyPI package, or Homebrew formula named Flux was found — the same org that publishes Agentic Orchestrator publicly has published nothing for Flux | Re-check on future harness-onboarding waves; graduates to a real integration the day a public artifact (repo, package, or binary) exists — see TD-398 |