Connector Firewall
External-effect connectors should not execute just because an upstream actor asked nicely. Put the connector behind a governed firewall boundary that verifies identity, policy, evidence, approval, descriptor integrity, and action recording before any outside effect occurs.
Problem
Delegated systems eventually need to touch the outside world: call a scanner, send an email, open a ticket, mutate a firewall, publish a post, or invoke a vendor API. If those connectors trust upstream intent, they become the place where governance is silently bypassed.
Context
Use this pattern when a system has external effects, tool calls, irreversible actions, regulated operations, security automation, delegated AI, worker execution, or vendor integrations. It is most important when the actor requesting action is not the same actor accountable for the result.
Forces
governed by a retry policy.
missing.
compromised-credential response instead of an incident-time debate.
instead of routing around it.
- External effects are narrow enough to look harmless and powerful enough to cause damage.
- Models, workers, and assistants can generate plausible requests without owning accountability.
- Approval may be scoped to a specific tool, descriptor, capability, evidence bundle, and action.
- The approval id must bind to the connector payload rather than remain a separate UI fact.
- Retrying an external effect can double-apply harm unless execution is idempotent, recorded, and
- Operators need one place to disable, inspect, and audit connector execution.
- The system must fail closed when policy, evidence, descriptor integrity, or approval state is
- Connector credentials eventually leak, expire, or get rotated; the boundary needs a deterministic
- Fallback execution paths are tempting during incidents and must preserve the connector firewall
Solution
Put every external-effect connector behind a firewall boundary. The connector firewall is not a network firewall. It is an architectural gate that refuses to execute until the system can prove who or what is requesting action, which action and capability are being invoked, which policy and risk tier apply, which evidence bundle grounds the request, whether approval is required and present, whether the connector descriptor is trusted, and where the immutable action record will be written. It must also evaluate revocation rules for approvals, delegated authority, connector state, and credentials before execution. Retries must re-check the same facts rather than inherit permission from the first attempt, and any repeatable external effect needs an idempotency key bound to the action record.
If any required fact is missing, stale, rejected, or unverifiable, the connector does less: queue, deny, require review, or stop.
Consequences
Tool execution becomes reviewable and repeatable. The system can explain why a connector was allowed to run, what evidence supported it, which approval authorized it, and what external result followed. Dangerous effects have one governed boundary instead of many informal shortcuts.
Failure Modes
- The connector assumes approval already happened upstream.
- The model can call tools directly after producing a confident answer.
- Approval covers a broad tool name instead of a specific action and capability.
- Descriptor integrity is checked during registration but not during execution.
- Retries repeat an external effect without an idempotency key or action record.
- A disabled connector can still execute through a worker, admin tool, or fallback path.
Proof Points
evidence, policy, approval where needed, connector integrity, and an immutable decision record.
enforcement seam so policy and evidence can decide without every path touching host state.
- AISDR — external security actions require identity,
- CapBan — firewall mutation is confined behind a single
Full source pattern: connector-firewall.md.