Key takeaways

• contro1 run, Claude Code hooks, and the Codex adapter all create the same canonical approval request.
• Project hooks are useful guardrails, but a developer who controls the hook or production credential can bypass them.
• For organization enforcement, keep production credentials out of the approval job and release them only to a protected deploy job after approval.
• The reviewer sees the exact redacted action, immutable hashes, target, policy trigger, and agent-reported justification as separate fields.

Choose the guarantee you actually need

A convenience gate stops an autonomous coding agent before a recognized deploy command and gives developers a fast, low-friction approval flow. It is ideal for evaluation and daily guardrails, but the developer can still remove a project hook or run the command elsewhere.

An enforced enterprise setup controls the coding-agent configuration centrally and moves production credentials behind protected CI or a deployment broker. The approval job has only a scoped Contro1 token; the deploy job receives short-lived production credentials only after the approval succeeds. This is non-bypassable for the governed path, assuming branch, environment, identity, and policy administration are themselves protected.

Five-minute polished demo

Use a harmless script first. Contro1 sends the redacted command, hash of the original argv, commit, workspace-state hash, environment, target, risk, and policy trigger to the CTO. The original argv bound to that hash runs only after approval, and the CLI blocks if the repository state changes while the request is waiting.

contro1 auth login --mode agent
contro1 init --name "deployment-demo"

contro1 run \
  --role cto \
  --risk critical \
  --environment production \
  --target billing-api \
  --reason "Production deploys require CTO authorization" \
  -- ./examples/production-deploy/simulate-deploy.sh

Safe production deploy demo

Claude Code template

The connector runs at Claude Code's PreToolUse boundary and, by default, gates deploy-like Bash commands. Tests, reads, and ordinary local work continue normally. Keep the agent token in user-level or managed settings, never in the repository.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "centcom-claude-code",
            "timeout": 910,
            "statusMessage": "Waiting for production deploy approval"
          }
        ]
      }
    ]
  }
}

Full Claude Code setup · Public connector

Codex template

The thin adapter reads a Codex PreToolUse or PermissionRequest event from stdin. It emits no decision for non-deploy Bash calls, so the normal Codex flow remains in control. It denies a recognized deploy on rejection, timeout, invalid policy, authentication failure, or API failure.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash
AI Control Plane for Enterprise AI Agents | Contro1
Control AI agents in production with human oversight built in. Contro1 routes approvals, escalations, and critical decisions to the right team by function, role, and shift.
What Contro1 does
Human-in-the-loop approvals for high-impact agent actions
Role-based routing to the right operator across departments
SLA timers and escalation paths for unresolved decisions
Signed webhook callbacks so workflows continue safely
Cross-framework coverage for modern AI agent stacks
Key links
Docs
Resource center
llms.txt
Security policy
quot;,
        "hooks": [
          {
            "type": "command",
            "command": "contro1 hooks codex --role cto --environment production --target billing-api --setup convenience",
            "timeout": 910
          }
        ]
      }
    ]
  }
}

Full Codex setup · Codex convenience and managed templates

GitHub Actions and CI template

Use two jobs. The approval job can read source and call Contro1, but it must not have cloud deploy credentials. The deploy job depends on approval, checks out the reviewed commit, enters a protected production environment, and obtains short-lived credentials through OIDC. Pin the Contro1 CLI release and every third-party action before production use.

A rejected, expired, timed-out, or unavailable approval fails the workflow closed. Protect changes to the workflow, environment reviewers, OIDC trust, and deployment policy with normal repository and identity controls.

jobs:
  approval:
    permissions:
      contents: read
    steps:
      - name: Wait for CTO approval
        env:
          CONTRO1_TOKEN: ${{ secrets.CONTRO1_AGENT_TOKEN }}
        run: contro1 requests create --file deploy-request.json --wait --format json

  deploy:
    needs: approval
    environment: production
    permissions:
      contents: read
      id-token: write
    steps:
      - name: Obtain short-lived production credentials and deploy
        run: ./scripts/deploy-production.sh

Complete GitHub Actions workflow

What the reviewer sees

Every path sends the same canonical request. context.action is the proposed tool and redacted input. context.machine_observed contains facts captured by the adapter, such as commit, command hash, workspace-state hash, target, and environment. context.agent_reported contains optional model-written justification and is never trusted for routing or risk. policy_trigger explains the organization rule. routing and approval_policy determine eligible reviewers, quorum, separation of duties, timeout behavior, and escalation.

Approve and Reject are the only decisions for a deploy approval. The API key decision_comment_policy controls whether the reviewer can decide with one click or must add a comment. A comment can explain a decision; it does not edit the command. If a different command is needed, reject and create a new request so the audit trail keeps both revisions clear.

Enterprise enforcement checklist

Distribute Claude Code or Codex hooks through managed configuration, prohibit unmanaged overrides and bypass modes, and install the adapter at an administrator-controlled absolute path. Remove standing production credentials from developer laptops. Require a protected CI environment or deployment broker to verify the approved request and bind it to the repository, commit, environment, target, and workflow run. Use short-lived credentials, protect policy changes, fail closed, and export the resulting decision and deployment evidence.

No client hook can secure another terminal by itself. The deployment system or credential issuer is the final enforcement point. Describe a setup as non-bypassable only within its explicitly governed identity and execution path.

Frequently asked questions

Is contro1 run a security boundary?

No. It is a strong convenience gate for the exact command it launches. A user who controls the machine and has direct production credentials can run another command outside it.

Does a managed coding-agent hook make deployment non-bypassable?

It makes the governed client path resistant to user or project configuration bypass. Protect production itself by keeping credentials behind protected CI or a deployment broker that releases them only after the approval.

Can an approver edit the deploy command?

Not in this release. The approver can approve, reject, and add a policy-controlled decision comment. A changed command must be submitted as a new request with new hashes.

Related resources