Fail Closed Before the Agent Acts: What Conduct's Guard-Before-Every-Tool-Call Model Means for Governing Deploy Agents

Every AI agent safety story in production today is told after the fact. The agent ran the migration, exfiltrated the secret, or pushed the broken deploy — and then the dashboard told you about it, complete with a trace you can replay and a shrug you can't. Conduct, a recent open-source launch (sseshachala/conductai, Apache 2.0), inverts that order: one policy decides block, warn, audit, or inject for every LLM call, every shell tool, and every MCP invocation before the action runs. If the policy engine can't verify what it's about to allow, nothing runs at all — fail-closed by default.

A reader opened this to get a concrete answer to one question: what does a fail-closed, pre-action gate actually buy a self-hosted PaaS whose agents can deploy, roll back, and read secrets? Here's the short version, up front — a Conduct-style decision table for the six actions a deploy agent reaches for most:

The rest of this post earns that table: what Conduct actually ships (verified against the repo, not the launch thread), why pre-action gating catches what post-hoc observability structurally can't, which production actions still need a human even when every policy pack verifies cleanly, and what a self-hosted PaaS should borrow versus build itself.

What Conduct actually ships​

Conduct is a control plane for AI agents with three surfaces and one policy:

• Guard is the policy engine. Configuration is workspace-signed — every Guard check verifies the signature before enforcing — and every decision appends to a SHA-256 hash-chained audit log rooted at workspace genesis, with an independent prev_hash/entry_hash verification procedure documented in the repo. If verification fails, Guard fails closed.
• Router is an LLM proxy. Any Anthropic-, OpenAI-, or Perplexity-speaking SDK points its base URL at /gateway/v1/*, and every request runs through Guard (policy, budget, audit) before reaching the upstream provider.
• Lens is a chat surface over the workspace, where every tool call the chat agent makes also runs through Guard.

Enforcement fires at three chokepoints: the CLI hook on every Claude Code, Cursor, Copilot, or Codex tool call; the MCP layer on every MCP tool invocation; and the Router on every LLM call from any SDK. One policy, three enforcement surfaces — the same rule follows a scheduled agent, a developer's Cursor session, and a chat session without being reimplemented three times.

The content library is what makes the engine usable on day one rather than after a quarter of policy authoring. The repo ships 15 compliance packs out of the box — OWASP, SOC 2 CC7.3, HIPAA §164.312, PCI DSS 4.0, EU AI Act articles 15/16, NIST AI RMF, ISO 42001, plus Python, Node, and Terraform packs — backing 183 guard rules, and 35 pre-built playbooks (issue-to-PR, code review, incident response, prod deploy gate, CI/CD triage, security-scanner triage, Slack digest), one YAML file each. Getting governed takes three commands — pip install conduct-cli, conduct login, conduct sync — or one docker compose up for a fully self-hosted control plane (API on port 8000, Canvas UI on 3000). Kubernetes deployment templates are tracked for fleet installs.

Two details matter for the evaluation that follows. First, the four decisions are not just allow/deny with synonyms: inject lets policy modify the action in flight (think redacting a secret from a tool argument rather than killing the whole call), which turns out to be the decision that makes secret-handling workable. Second, the hosted tiers gate enforcement, Router, and hash-chain verification behind paid plans while Discovery stays free — the open-source repo is the whole runtime, but the audit-verification story you show an auditor is partly a commercial surface. Self-hosters should know exactly which half they're relying on.

Why pre-action beats post-hoc for PaaS tools​

The incumbent model — agent observability — records everything and judges afterward. That's genuinely useful for debugging ("why did the agent retry the deploy four times?"), but it has a structural hole for platform operations: the judgment arrives after the state change. A trace of a bad production deploy is an incident report, not a control.

A pre-action gate closes that hole at exactly the seam where a PaaS is most exposed: the tool call. Take the concrete scenario — an agent pushing a production deploy at 2am because a retry loop decided the third attempt would succeed — and watch the two models diverge:

This isn't a hypothetical architecture — the ecosystem already converged on its primitives. Claude Code's PreToolUse hooks apply most-restrictive-wins precedence (deny beats ask beats allow), so a single deny from any hook kills the call before it runs. MCP's elicitation mechanism (June 2025 spec, matured through 2026) standardizes the server-driven, mid-tool-call user prompt — the consent path a held action uses to reach a human. And the NSA and CISA guidance on agentic AI says the same thing in regulator language: deny lists and non-overridable safety constraints up front, least-privilege access, detailed logs of agent decisions for audit afterward. Conduct's contribution is packaging all three — the hook point, the consent path, the tamper-evident log — behind one policy instead of three hand-wired integrations.

The honest caveat: pre-action gating only governs actions that flow through its chokepoints. An agent with raw kubectl credentials and no CLI hook installed bypasses the CLI gate entirely; a side-channel API call that isn't an MCP tool never sees the MCP layer. Fail-closed means "deny what I can't verify," not "verify everything." A PaaS adopting this model has to treat chokepoint coverage — every agent path funnels through a gate — as the actual security property, not the policy count. Fifteen packs mean nothing if the agent's shell isn't hooked.

What still needs a human​

Here's the boundary the launch thread doesn't emphasize enough: some production actions must require human approval even when every policy pack verifies cleanly. Policy can encode rules; it can't encode intent, and it can't un-ship consequences. Four categories stay human-gated on any sane PaaS:

1. Production deploys. A policy can verify the image is signed, the tests passed, and the deploy window is open — and still have no idea whether this deploy is the one the team wants. "Correct artifact, wrong moment" (during an active incident, during a freeze nobody encoded) is a judgment call. The gate's job is to hold the action and route it to a human, not to approve it.
2. Destructive migrations. Anything irreversible — dropping a table or column, backfilling with a lossy transform, deleting tenant data — fails the "can we undo this at 3am" test. The right default is block for the destructive shape outright, with a narrow, human-approved exception path, because no compliance pack can distinguish "drop the deprecated column" from "drop the wrong column."
3. Secret reads shaped like exfiltration. Reading a secret to inject it into a deploy tool call is routine; reading every secret in the vault into the model's context window is an exfiltration pattern wearing a legitimate API call. Policy can flag the shape (bulk reads, reads outside a deploy flow, secrets leaving toward an unapproved destination), but confirming "yes, this bulk export is the sanctioned rotation" needs a human who knows the rotation is happening.
4. Fleet-wide rollouts and topology changes. Scaling one app by one replica is arithmetic; doubling the fleet, draining a node pool, or changing cluster topology commits money and availability at a scope no single deploy policy reasons about. Threshold-based warn-then-approval is the workable shape: routine scaling flows, step-changes pause.

The through-line: keep the human where the blast radius is large, the action is irreversible, or the correctness condition lives outside anything policy can observe. Everything else — staging deploys, rollbacks, routine scaling, scoped secret injection — should flow through audit and warn without a human in the loop, or the gate becomes the bottleneck the team routes around, and then you have neither velocity nor safety.

What a self-hosted PaaS borrows vs. builds​

For a platform team running its own machines, Conduct is Apache 2.0 and self-hosts in one docker compose command — but "adopt the whole control plane" isn't the only option, and for a PaaS it probably isn't the first one. The borrow/build split that falls out of the evaluation above:

The highest-leverage borrow is the MCP-layer gate in front of deploy tools, because that's where a self-hosted PaaS is currently weakest. Most platforms expose deploy-from-chat (or will, now that Render's MCP server set the baseline) with auth but no policy layer between "the agent is authenticated" and "the agent called trigger_deploy on production." A block/warn/audit/inject gate at that exact seam — with holds routed to a human through MCP elicitation — is the difference between an agent surface and an agent incident waiting for its 2am page.

The piece to build, not borrow, is tenant-aware policy. Conduct's unit of governance is the workspace; a PaaS's unit is the tenant, the app, and the team inside the tenant. Per-app deploy windows, per-team approval chains, secret scoping that follows app boundaries — that policy model lives in the platform, because only the platform knows where one tenant ends and the next begins.

The direction of travel is clear enough to bet on: agents are becoming first-class operators of the platforms they deploy to, and "we log everything" is being replaced by "we verify before anything runs." Fail-closed gating at the tool-call seam, signed policy, a hash-chained record of every decision, and a human held in the loop exactly where blast radius demands it — that's the shape of agent governance that survives contact with production. Conduct packaged it first; the pattern is what matters, and it's one every self-hosted PaaS will need to either adopt or reimplement.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.