How Do I Safely Deploy Agents Across CI and Production?

Why Can't I Use the Same Security Model for Local Dev and CI Agents?

Because local dev agents and CI agents operate in fundamentally different threat environments, even when they use the same tools. The Hablich framework classifies deployments into three trust tiers:

- Tier 1 (local dev): Human is in the loop. Default browser profile, local data access. Every sensitive action requires explicit, time-bound human consent.

- Tier 2 (CI/controlled): No human in the loop. Requires data separation — containers, separate browser profiles, remote debugging port isolation.

- Tier 3 (full internet access): Domain allow lists, prompt injection mitigations, and all Tier 2 controls, plus maximum process isolation.

The critical rule: tools can be shared across tiers, but the security model must never be shared. A `navigate_to_url` tool works the same everywhere, but in Tier 1 it requires consent, in Tier 2 it runs in a container, and in Tier 3 it's restricted to an allow list.

What Security Risks Do Convenience Features Create in Agent Deployments?

In traditional UX, removing friction is always a win. In agentic systems, some friction is by design. Features like auto-remembering permissions, autoconnect (sharing sessions without repeated consent), or blanket tool approvals feel like UX improvements but actually remove consent checkpoints that protect against prompt injection.

The Lethal Trifactor (Simon Willison's framework) identifies converging risks in agentic automation that make prompt injection particularly dangerous. The Hablich framework responds by treating any convenience request that eliminates a consent checkpoint as a security risk to be evaluated, not a UX win to be shipped.

For Tier 2 CI deployments, the mitigation is different: since no human is present, security comes from isolation (containers, separate profiles, network controls) rather than consent prompts.

How Do I Set Up Data Separation for Tier 2 Agent Deployments?

Tier 2 deployments in CI require three forms of isolation:

1. Container isolation — each agent run should execute in a fresh container with no access to persistent state from previous runs.

2. Separate browser profiles — if agents use browser automation, use isolated profiles that contain no credentials, cookies, or session data from real users or other agent runs.

3. Remote debugging port security — if using Chrome DevTools Protocol or similar, bind debugging ports to localhost only and use unique ports per container to prevent cross-agent communication.

Do not rely on a single isolation mechanism. Layer them. And never promote a Tier 2 setup to Tier 3 (internet-facing) without adding domain allow lists and prompt injection mitigations.

How Do I Monitor Agent Security Across Tiers in Production?

Instrument each tier separately. Track consent events in Tier 1 (how often agents request permissions, how often humans approve or deny). Track isolation violations in Tier 2 (container escapes, cross-profile data access, unexpected network calls). Track domain access patterns in Tier 3 (requests outside allow lists, unusual navigation patterns that suggest prompt injection).

Combine security monitoring with the framework's fuel-efficiency metrics — tokens per successful outcome per journey. An unusual spike in token cost for a journey that normally costs little can indicate the agent is being manipulated into unnecessary actions.

Next step: Audit your current agent deployments and classify each into Tier 1, 2, or 3. For any deployment where you find the same security model applied across tiers, create a remediation plan to separate them immediately.