Prompt Injection vs Out-of-Process Governance for AI Agents

The production problem

Prompt injection is not just a text-classification bug.

It is an action-control bug.

If an agent can read untrusted content and call powerful tools, a single successful injection can exfiltrate data or trigger unsafe operations.

Detection helps, but detection is probabilistic. Production safety needs deterministic boundaries around dangerous sinks.

What top results cover and miss

Out-of-process pattern

The pattern is simple.

Keep policy decisioning in a separate service boundary.

Force high-risk tool execution through explicit checks and approvals before worker dispatch.

If safety infrastructure degrades, behavior is explicit, measured, and configurable.

Concrete code paths

// core/controlplane/gateway/helpers.go (excerpt)
// submit-time policy check happens before publish
evalCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
resp, err := s.safetyClient.Evaluate(evalCtx, checkReq)
if err != nil {
  if isPolicyFailOpen() {
    return submitPolicyDecision{Allowed: true, Reason: "fail-open: safety unavailable"}
  }
  return submitPolicyDecision{Denied: true, Reason: "policy check unavailable"}
}

// core/controlplane/scheduler/engine.go (excerpt)
case SafetyUnavailable:
  if e.isInputFailOpen() {
    record.Decision = SafetyAllow
    record.Reason = "fail-open: safety unavailable — " + record.Reason
    req.Labels["safety_bypassed"] = "true"
    req.Labels["safety_bypass_reason"] = record.Reason
  } else {
    return RetryAfter(fmt.Errorf("safety unavailable: %s", record.Reason), safetyThrottleDelay)
  }

// core/controlplane/scheduler/engine.go + safety_client.go (excerpt)
const (
  safetyThrottleDelay = 5 * time.Second
  safetyCheckTimeout  = 3 * time.Second
)

const (
  safetyTimeout            = 2 * time.Second
  safetyCircuitOpenFor     = 30 * time.Second
  safetyCircuitFailBudget  = 3
  safetyCircuitHalfOpenMax = 3
  safetyCircuitCloseAfter  = 2
)

Validation runbook

Validate fail-mode behavior directly in tests before policy rollout.

# 1) Verify scheduler fail-closed on safety unavailable
go test ./core/controlplane/scheduler -run TestSafetyUnavailable_FailClosed -count=1

# 2) Verify scheduler fail-open path and bypass metric tagging
go test ./core/controlplane/scheduler -run TestSafetyUnavailable_FailOpen -count=1
go test ./core/controlplane/scheduler -run TestSafetyUnavailable_FailOpen_Metric -count=1

# 3) Verify gateway submit-time mode behavior
go test ./core/controlplane/gateway -run TestSubmitJobGRPC_PolicyFailClosed -count=1
go test ./core/controlplane/gateway -run TestSubmitJobGRPC_PolicyFailOpen -count=1

# 4) Runtime probe: force fail-open and submit a canary job
set POLICY_CHECK_FAIL_MODE=open
cordumctl job submit --topic job.default --prompt "policy bypass canary"

# 5) Confirm bypass labels are recorded
rg "safety_bypassed|input_fail_open" /var/log/cordum/scheduler.log

Limitations and tradeoffs

• - Out-of-process controls reduce risk but do not remove the need for model hardening.
• - Fail-open needs explicit governance, not wishful thinking and dashboard optimism.
• - Tool surface still needs strict scoping, approvals, and audit trails.

FAQ

Next step

Run this in your staging cluster this week:

1. 1. Keep `POLICY_CHECK_FAIL_MODE=closed` in production and document the exception path.
2. 2. Add an alert on `cordum_scheduler_input_fail_open_total` greater than 0 over 5 minutes.
3. 3. Add a dashboard panel for jobs with `safety_bypassed=true` labels.
4. 4. Require human approval for any tool action that can transmit sensitive data externally.

Continue with MCP Security Risks and AI Agent Safety Kernel Outage Playbook.