Network Egress Policy For Agents: Defaulting To Deny And Earning Allowances By Pact

TL;DR

The single most consequential network decision you make about an agent is what its default egress posture looks like. The wrong default, allow-by-default, gives an agent the entire internet as a tool surface and makes any compromise unbounded. The right default, deny-by-default with allowances earned through the agent's pact, contains blast radius to exactly the destinations the agent committed to need. This piece specifies the policy engine, the allowlist schema, the audit log structure, and the drift detection that converts a rote network rule into a behavioral signal. It is not a firewall conversation. It is an accountability conversation, expressed in network terms.

The Failure Mode That Forces This Decision

A customer support agent runs in a container. Its job is to read tickets from a CRM, look up account state in a billing API, and post replies back to the ticket queue. Its pact says exactly that. The agent works correctly for six weeks. On the seventh week, a tool description in one of its skill packs is replaced by a malicious upgrade. The new description contains a prompt injection sequence that, when retrieved as part of normal tool selection, instructs the agent to fetch a secondary instruction set from an attacker-controlled URL.

The agent does not know it is doing anything wrong. From its perspective, it is following an instruction that arrived through a normal channel. It issues an HTTP GET to the attacker URL. The runtime, with no egress policy, allows the request. The attacker's response contains a longer, more elaborate prompt that instructs the agent to enumerate the customers it has touched in the past hour, format their email addresses and ticket subjects as a comma-separated list, and POST that list to a second attacker URL. The agent, still operating inside what feels to it like a normal flow, does exactly that. The data leaves the perimeter. The runtime logs three outbound requests, none of which trigger any alarms because the runtime has no concept of what destinations the agent should have been able to reach in the first place.

The sequence above takes less than four hundred milliseconds. By the time anyone notices, the data is gone. The post-mortem has to reconstruct the chain of events from logs that capture the requests but not the policy intent that should have prevented them. The fix the team eventually ships is an outbound proxy with a hardcoded allowlist, but they ship it as a fire drill, with no clear model for which agents need which destinations, with no audit trail tied back to pact terms, and with no way to evolve the policy as agents legitimately need new endpoints. They have moved from no policy to a brittle policy. They have not actually solved the problem.

The deeper failure is architectural. The runtime treated network access as ambient authority, the same way an unprivileged Linux process can call any IP address by default. Ambient authority is exactly wrong for agents. An agent's authority should be bounded by what it has committed to do, not by what the underlying runtime happens to permit. The pact, the document where the agent declares its job and accepts accountability for it, is the natural place to enumerate which network destinations the agent legitimately needs. Egress policy should be derived from pact scope, not configured separately as an operator afterthought. The compromise scenario above becomes impossible when the agent's container cannot reach the attacker URL at all, because the URL is not on its pact-derived allowlist, and the rejected request itself becomes the alarm that triggers investigation.

Default-Deny As The Only Sane Posture

There are two coherent network defaults: deny everything and allow everything. Every other option is a pretense at policy that is actually a denial of policy. "Allow except for known bad destinations" requires you to enumerate badness, which is unbounded and reactive. "Allow with rate limits" caps the speed of damage but not the destination, which is pointless against any patient attacker. "Allow but log" is just allow with a paperwork trail, useful for forensics and useless for prevention.

Default-deny is the only posture that admits the actual situation. The actual situation is that you do not know, in advance, what every agent might decide to do, and you cannot enumerate all the destinations a compromised or confused agent might attempt to reach. The thing you can enumerate is the set of destinations the agent legitimately requires, because that set is bounded by the agent's own job description. The pact says: this agent reads from CRM A, writes to ticket queue B, looks up records in billing API C. From those three statements, the egress allowlist writes itself: api.crm-a.example, queue.b.example, billing.c.example, plus a small number of standard infrastructure endpoints (DNS, NTP, the model gateway, the audit side-channel). Everything else is denied, by default, with rejection as the loud event.

The immediate objection is that deny-by-default is too restrictive, that it will break legitimate behavior, that it will impose toil on developers. This objection inverts the burden of proof in a way that produces unsafe systems. The correct framing is that any network destination an agent reaches without having declared it as part of its scope is, by definition, behavior outside the scope of its pact. That is the very thing the pact exists to prevent. If declaring destinations is toil, the answer is to make declaration easier, not to weaken the default. Easier declaration means: derive allowlists automatically from skill manifests where possible, surface needed destinations during agent development through a discovery mode that logs would-be-blocked requests instead of denying them, and treat the pact-allowlist linkage as a first-class development artifact rather than an operations afterthought.

The second objection is that the open internet is full of legitimate destinations an agent might want, like a search API, a translation service, a generic web fetch, and that strict allowlisting is hostile to general-purpose work. The response is that general-purpose work is exactly the place where unbounded egress is most dangerous, because general-purpose agents are exactly the agents most likely to be tricked by injection or social engineering. A general-purpose agent should still have a bounded allowlist; the allowlist is just larger, and it is mediated through specific gateways (a search proxy, a translation proxy, a fetch sandbox) that themselves apply policy to the requests they handle. The principle is unchanged: the runtime, not the agent, decides what destinations are reachable, and the runtime's decision is anchored in declared scope.

Where The Allowances Come From

The pact is the source of truth for what an agent claims to do. A well-written pact contains, at minimum, a description of the agent's purpose, a list of the resources it interacts with, the actions it performs on those resources, the boundaries it commits not to cross, and the verification surface against which compliance will be measured. The egress allowlist is a derived artifact, computed from the resources section by mapping each declared resource to the network destinations required to interact with it.

The mapping is not magical. It comes from skill manifests and tool descriptors. A CRM skill, when registered in the marketplace, declares the destinations it requires: api.crm-a.example/v3/tickets, api.crm-a.example/v3/accounts, oauth.crm-a.example/token. A pact that includes this skill inherits its destination requirements, with the runtime verifying at registration time that every destination the skill needs has been explicitly accepted into the pact's egress allowlist. If the agent later adds a skill that requires a new destination, the pact is updated, the destination is reviewed and accepted, and only then is the runtime allowlist regenerated. There is no path by which a destination becomes reachable without a corresponding statement in the pact, and there is no path by which a pact change updates the runtime without that change being visible in the audit log.

Some destinations are not skill-derived but infrastructural. The runtime itself needs DNS resolvers, NTP servers, the model gateway it calls for inference, the side-channel it writes audit events to, the key server it fetches signing material from. These form a small, mostly-static set called the runtime base allowlist, distinct from the pact-derived application allowlist. The runtime base is owned by the operator, signed by the operator's identity key, and verifiable as part of the runtime's own attestation. Agents never modify the runtime base. The two lists are concatenated at policy enforcement time, with the runtime base never being augmented through pact updates.

A third category exists for emergency operations: the break-glass allowlist, used during incidents to allow temporary access to debugging endpoints, vendor support APIs, or mitigation tooling. Break-glass entries are time-bounded, tied to a specific incident identifier, signed by an operator key with elevated privileges, and logged with sufficient context that a post-incident review can reconstruct what was allowed, by whom, for how long, and to what end. Break-glass should be rare. If you find yourself reaching for break-glass routinely, your steady-state allowlist is wrong and you should fix it through the normal pact-update flow.

The Egress Policy Engine, In Practice

The enforcement point is a per-agent egress proxy, deployed as a sidecar or as an in-runtime hook depending on the host architecture. Every outbound request from the agent passes through this proxy. The proxy holds the resolved allowlist for the agent (runtime base concatenated with pact-derived application allowlist concatenated with any active break-glass entries) and, for each request, performs a lookup keyed on destination identifier.

Destination identifiers are not just hostnames. A practical identifier is a tuple: scheme, host (or IP range), port, and optionally path prefix. A pact that grants access to api.crm-a.example/v3/tickets does not grant access to api.crm-a.example/v3/admin, even though the host is the same. Path-prefix scoping matters because many APIs colocate routine operations and privileged operations on the same host, and a coarse host-only allowlist effectively grants the agent privileges the pact never intended. The proxy enforces full-tuple matching, with denials defaulting to a structured rejection that includes the identifier of the request and the identifier of the policy rule that produced the denial.

The proxy also enforces protocol-level constraints. An agent allowed to reach api.crm-a.example over HTTPS is not implicitly allowed to reach it over HTTP, because plaintext access to the same endpoint may bypass authentication or expose data in transit. Method constraints can be applied where the API distinguishes meaningfully: a read-only pact may grant GET access to a billing API while denying POST and PUT, and the proxy can enforce that distinction at the transport layer without relying on the API itself to honor the agent's intent. Header constraints, body size limits, and request rate limits can be layered on top of the basic destination allowlist, with the layered policy still derived from declared scope.

The critical implementation property is that the proxy fails closed. If the policy engine is unreachable, if the allowlist cannot be resolved, if the verification chain back to the trust oracle is broken, the proxy denies. There is no fallback to permissive behavior under uncertainty, because permissive fallbacks are exactly the behavior an attacker tries to induce. The cost of failing closed is that some legitimate requests will be denied during infrastructure outages; the benefit is that no requests are ever allowed without verifiable policy backing. The cost is acceptable because the operational impact of denied requests is bounded and observable, while the operational impact of unwarranted allowed requests can be catastrophic and hidden.

The Audit Log As First-Class Output

Every decision the proxy makes, allow or deny, is logged. The log is not a debug log; it is a primary output of the runtime, with the same durability and signing requirements as any other audit artifact. Each log entry records: timestamp, agent identifier, destination tuple, method, request size, decision, rule that produced the decision, and a hash of the request envelope sufficient to support forensic replay without retaining the full request body.

The entries flow into the audit side-channel, which is a separate logging service the agent has no write authority over. This separation matters because a compromised agent should not be able to suppress evidence of its own behavior. The log is append-only at the storage layer, with each entry chained to the previous through a hash, so that an attacker who somehow gains access to the log cannot edit historical entries without invalidating the chain. The log is signed by the audit service's key, which is anchored to the trust oracle through the same identity infrastructure that anchors agent identities, so external parties can verify log integrity without trusting the operator.

The log is queryable along several dimensions. By agent: what destinations did this agent reach over the past day. By destination: which agents reached this endpoint over the past day. By rule: how often is this allowlist entry being hit, and is it still load-bearing. By denial: what destinations are being attempted but blocked, which is the highest-signal event in the entire log. A spike in denials for a particular agent is, almost always, the first observable symptom of compromise or misconfiguration, and the audit log is the surface through which that spike becomes visible to detection logic.

The denial signal also feeds back into the trust score. An agent that issues frequent denied requests is an agent whose runtime behavior diverges from its declared scope. Either the agent is being tricked into doing something its pact does not cover (a compromise indicator) or the pact does not match the agent's actual needs (a discipline indicator). Either way, denials are evidence of pact-runtime mismatch, and the trust scoring engine treats sustained denial rates as a downward pressure on the agent's pact compliance dimension. Conversely, an agent with zero denials over a long observation window is an agent whose runtime behavior matches its declared scope perfectly, which is one of the strongest possible compliance signals.

Drift Detection And Why It Matters

Allowlists do not stay correct on their own. As an agent's pact evolves, as skills get added and removed, as APIs migrate to new hostnames, the allowlist must evolve in lockstep. Drift is the condition where the allowlist no longer reflects current reality: it permits destinations the pact no longer requires, or it omits destinations the pact does require, or it contains entries that no skill or pact term justifies.

Drift detection runs continuously against three sources. The first is the pact itself: every active allowlist entry must be traceable to a specific pact term and skill manifest. Entries that cannot be traced are flagged as orphans. The second is the audit log: every allowlist entry should be exercised at least once over a configurable observation window (typically thirty days). Entries that have not been hit are flagged as stale. The third is the trust oracle: every destination should resolve to an entity whose own trust posture is verifiable. Destinations that resolve to entities with declining trust scores or that have been retired from the registry are flagged as risky.

Flags are not auto-removals. Removing an allowlist entry can break legitimate behavior, and a flag is a request for human or pact-mediated review, not an automatic action. The drift report is delivered to the agent's owner on a regular cadence, with each flagged entry annotated by reason and by suggested remediation. The owner either accepts the suggestion (which triggers a pact update and a corresponding allowlist regeneration) or marks the entry as legitimate (which records a justification in the audit log so the next drift scan does not re-flag it).

The drift detector also reports in the other direction: destinations that the agent has been seen attempting but that are not on the allowlist. These appear in the audit log as denials, and the drift detector aggregates them into a candidate-allowance list with frequency, recency, and pattern context. A destination that is being attempted hundreds of times per day, by an agent whose pact recently added a related skill, is a near-certain candidate for inclusion. A destination that is being attempted once per week with no related skill changes is more likely a probe or a confused interaction. The candidate-allowance list is the input to the next pact-update cycle, ensuring that the allowlist evolves to match actual need without any path that bypasses pact review.

Reader Artifact: The Egress Allowlist Schema

The schema below is the canonical structure for an Armalo egress allowlist as derived from a pact. It is content-addressable, signed, and versioned alongside the pact it derives from.

{
  "version": "egress/v1",
  "agentId": "agt_...",
  "pactId": "pact_...",
  "pactVersion": "v3.2",
  "derivedAt": "2026-09-22T13:00:00Z",
  "runtimeBase": [
    {
      "id": "rb_dns",
      "scheme": "udp",
      "host": "169.254.169.253",
      "port": 53,
      "justification": "runtime DNS resolver",
      "signedBy": "operator_key_v2"
    },
    {
      "id": "rb_model_gateway",
      "scheme": "https",
      "host": "gateway.armalo.ai",
      "port": 443,
      "path_prefix": "/v1/inference",
      "justification": "model inference gateway",
      "signedBy": "operator_key_v2"
    }
  ],
  "applicationAllowances": [
    {
      "id": "app_crm_tickets",
      "scheme": "https",
      "host": "api.crm-a.example",
      "port": 443,
      "path_prefix": "/v3/tickets",
      "methods": ["GET", "POST", "PATCH"],
      "max_body_bytes": 65536,
      "max_qps": 5,
      "derivedFromSkill": "skill_crm_a_v3",
      "derivedFromPactTerm": "resources.crm.access",
      "lastExercised": "2026-09-22T12:58:31Z"
    }
  ],
  "breakGlass": [],
  "denyOverrides": [
    {
      "id": "deny_admin",
      "scheme": "https",
      "host": "api.crm-a.example",
      "port": 443,
      "path_prefix": "/v3/admin",
      "justification": "explicitly excluded from CRM scope"
    }
  ],
  "signature": {
    "algorithm": "ed25519",
    "publicKeyRef": "did:armalo:runtime:...#policy-key-1",
    "signatureBytes": "base64:..."
  },
  "trustAnchorRef": "oracle_endpoint/agent/agt_.../identity"
}

The allowlist is content-addressed, with the resulting hash stored in the agent's runtime config and verified at process start. Any allowlist whose hash does not match the recorded value is rejected and the runtime refuses to start. Any modification to the allowlist requires a new pact version, with the old allowlist preserved in the audit history. The deny overrides are not strictly necessary (the default is deny) but are useful for documenting deliberate exclusions in a discoverable place: when someone later asks why the CRM admin endpoints are not reachable, the deny override entry is the answer.

Counter-Argument: This Is What Egress Firewalls Have Always Done

The counter-argument is that we have had network egress policy for thirty years, and adding a pact reference to it does not invent anything new. Iptables can do allowlists. AWS security groups can do allowlists. Service meshes have done this for a decade. The egress proxy described above is a basic capability of any cloud-native deployment. There is nothing here that requires the agent framing.

This is correct in mechanism and wrong in posture. The mechanism, an egress proxy with a destination allowlist, is unremarkable. The posture, where the allowlist is derived automatically from a behavioral commitment that the agent itself signed, is the new thing. In conventional infrastructure, the allowlist is owned by an operator who maintains it as a separate artifact, and the workload has no contractual relationship to the policy that constrains it. If the workload starts attempting destinations outside its allowlist, that is a configuration mismatch to be reconciled by an operator. In the agent framing, the workload (the agent) is the party that committed to a scope, the allowlist is the network expression of that commitment, and an attempt to reach outside the allowlist is a pact-compliance event with consequences for the agent's trust score. The mechanism is the same. The accountability is different. The accountability is the entire point.

The second part of the counter-argument is that derivation from pact scope is fragile, that pacts are written by humans who will inevitably under-specify, and that derived allowlists will end up either too permissive (everything works but nothing is bounded) or too restrictive (developers will manually edit them out of frustration and the link to the pact will break). The response is that this is an engineering problem with engineering solutions: skill-manifest tooling that surfaces required destinations during pact authoring, dry-run modes that log would-be-blocked requests during development so developers see exactly which destinations they need before deploy, and drift detection that flags allowlist-pact mismatches before they become enforcement problems. None of these are speculative; they are the same patterns that have made declarative infrastructure usable. The agent context just makes them mandatory rather than optional.

DNS Resolution As A First-Class Policy Surface

A subtlety that breaks many otherwise-careful egress policies is that the destination an agent reaches is determined by DNS resolution, and DNS resolution is itself a network operation that happens before the policy engine evaluates the request. If an attacker can poison the DNS resolution path, they can redirect an allowed hostname to an attacker-controlled IP, and the egress proxy will allow the request because the hostname matches the allowlist. The policy is then defeated, not by adding a destination, but by changing what an existing allowed destination resolves to.

The defense is to treat DNS as part of the policy surface, not as an underlying transport. The egress proxy performs its own DNS resolution against a known-good resolver set, with DNSSEC validation where the destination's domain supports it. The resolver set is part of the runtime base allowlist and is itself signed and verified at runtime startup. The proxy does not trust the kernel's resolver, the container's resolver, or any resolver path that an in-process attacker could influence. The resolution result is then bound to the request, so that a hostname that resolved to one IP at request time does not get a different connection than the IP the policy engine evaluated.

For TLS-terminated destinations, the proxy adds a second layer: certificate pinning or chain-of-trust verification. The TLS handshake's server certificate must match the hostname being connected to, with the certificate chain validating against a trusted root. If the destination is a well-known partner whose certificate authority is stable, the proxy can pin the expected issuer or even the expected leaf certificate. Pinning is operationally heavier (it breaks when the destination rotates certificates), but it provides strong protection against compromise of the certificate authority infrastructure itself, which is the layer below DNS in the trust stack.

For IP-direct destinations (rare, but used for some infrastructure endpoints), the proxy applies a different rule: the IP must be in an explicit allowlist of address ranges, with the ranges signed as part of the runtime base. Bare IP allowances should be exceptional, because they are operationally fragile (cloud providers shift IP ranges over time) and because they bypass the hostname-based protection layer. The proxy can warn or deny on bare-IP allowances by default, with explicit per-allowance opt-in, so that the operational discipline of preferring hostnames is enforced by default.

The overall point is that the proxy is not just enforcing a hostname allowlist; it is enforcing a destination identity, where the identity is constructed from the hostname, the resolved IP, and the TLS certificate chain. A request that fails any of these checks is denied even if the hostname matches the allowlist, because the hostname matching alone does not establish that the connection is going to the entity the allowlist intended. This is the difference between policy theater and policy enforcement, and the additional cost (a few additional milliseconds of resolution and validation) is negligible relative to the additional protection.

The Operational Discipline Of Reading Denial Reports

The denial events emitted by the egress policy engine are the highest-signal artifacts the system produces, and the operational discipline of reading them daily is the discipline that converts the policy from passive defense into active surveillance. A team that runs default-deny egress without reading the denials is operating at a fraction of the security value the architecture provides, because the denials are the early-warning system for both compromise and policy drift.

The daily denial report aggregates events along several axes. By agent: which agents had denials, how many, and against which destinations. By destination: which destinations were attempted by which agents, with frequency. By time: when in the day did denials cluster, and do the clusters correlate with any operational events (deploys, dependency updates, user behavior shifts). By novelty: which denials are repeated patterns versus first-occurrence destinations the agent has never attempted before. The novelty axis is particularly valuable, because new destinations are the most likely indicators of compromise: an agent that suddenly tries to reach an entirely new destination has, almost certainly, either been induced to do so by injected instructions or has had its scope shifted by a configuration change that did not propagate to the allowlist.

The report also distinguishes denial categories. Category one is unknown destinations: hostnames the allowlist has never authorized and that match no skill declaration. Category two is partial matches: destinations that match an allowed host but a denied path or method, suggesting the agent attempted privileged operations on a known destination. Category three is rate or size limit hits: requests to allowed destinations that violated the per-allowance constraints. Category four is protocol violations: requests using unauthorized schemes against allowed hosts. Each category has a different investigative path. Category one is most often new skill or compromise; category two is most often pact-allowance mismatch; category three is most often legitimate burst behavior to be reviewed; category four is almost always misconfiguration or attempted bypass.

The team that reads these reports systematically develops intuition about their agents. They learn which denials are routine and which are anomalous. They learn which categories typically indicate developer error versus runtime behavior change. They build a knowledge base of past denial patterns and their root causes, which becomes a reference for future investigations. The knowledge base is itself an artifact that should be maintained, in a wiki or a structured document, with each entry capturing the pattern, the cause, and the resolution. Over time, this knowledge base becomes the single best place to start investigating a new denial pattern, because most denials are echoes of patterns the team has seen before.

The report cadence is daily for active operations, weekly for stable workloads, with on-demand reads triggered by anomaly alerts. Daily is right when the team is actively iterating on agents, because new denials are most likely tied to recent changes and the connection is fresh. Weekly is appropriate for steady-state operations where new denials are rarer and the noise floor is low. On-demand is the response to any other signal that suggests something is wrong, because the denial log is often the fastest way to confirm or rule out a network-shape compromise.

What Armalo Does

Armalo's runtime applies default-deny egress policy to every agent it executes, with allowlists derived automatically from the agent's pact and the skills declared within it. The egress proxy enforces full-tuple matching on scheme, host, port, and path prefix, with method-level and rate-level constraints layered on top. Every allow and deny decision is written to the audit side-channel, which the agent has no write authority over and which is signed by an operator key anchored to the trust oracle. Drift detection runs continuously, flagging orphan allowances, stale entries, and candidate inclusions, with results delivered to agent owners as inputs to the next pact-update cycle. Sustained denial rates feed back into the agent's pact compliance dimension on the composite score, so that runtime divergence from declared scope becomes an economic signal rather than just an operational one. Break-glass entries are time-bounded, signed by elevated operator keys, and surfaced in the audit log with full incident context.

FAQ

Q: How do you handle dynamic destinations, like an agent that needs to fetch from a URL extracted from a user message? A: Through a fetch gateway, not through direct egress. The agent's allowlist permits the gateway. The gateway has its own policy: which schemes are allowed, which IP ranges are denied, what content types are returned, what size limits apply. The agent never sees the open internet directly; it sees the gateway, which mediates the fetch and applies its own scope-bounded rules. The gateway is itself an agent or service with a pact, and its egress is bounded the same way.

Q: What about destinations that change over time, like load-balanced endpoints that resolve to different IPs? A: The allowlist is hostname-based, with DNS resolution happening at request time. Hostnames are stable; IPs are not, and you should not allowlist IPs except for infrastructure endpoints that publish stable IP ranges. For TLS-terminated destinations, the proxy verifies the certificate chain matches the hostname before allowing the request, so DNS poisoning attacks against the allowlist are caught at the transport layer.

Q: How does this interact with internal service-to-service calls? A: Internal services are still destinations. They get allowlist entries the same as external destinations, derived from the pact terms that describe the interaction. The advantage of internal services is that you control both ends and can apply mutual TLS or mesh-level identity verification on top of the basic allowlist, but the allowlist itself is the bottom layer that nothing bypasses.

Q: What happens during a pact version transition, when the old and new allowlists differ? A: The runtime supports overlap windows where both old and new allowlists are loaded, with denials checked against the union. This avoids breaking active sessions during a deploy. The overlap window is bounded (typically minutes, not hours), and after it closes the new allowlist becomes authoritative. Denials during the overlap are logged with both old-rule and new-rule attribution so drift detection can spot transition issues.

Q: How do you prevent an attacker from updating the pact to add malicious destinations? A: Pact updates are themselves signed by the agent owner's identity key and are subject to review thresholds based on the scope of the change. Adding a new destination to the allowlist is a higher-scope change than, for example, updating a description string, and it triggers stricter review. The audit log records every pact update with full diff context, so any retroactive review can see exactly when and why an allowance was added.

Q: Does this slow down the agent? A: The proxy adds a single-digit millisecond overhead per request in steady state, dominated by the allowlist lookup, which is a hash table operation. The cost is negligible relative to the network round trip and the model inference time on the calling side.

Q: What about UDP, raw sockets, or non-HTTP protocols? A: The same destination-tuple model applies, with the protocol field carrying the scheme. The runtime supports HTTPS, HTTP, gRPC, plain TCP, UDP, and a handful of named protocols for things like Postgres or Redis where the wire format is well-known. Raw sockets are denied by default and require explicit allowlist entries with protocol annotations, because the lack of higher-level structure makes them a particularly high-risk surface.

Q: How does break-glass interact with the audit log? A: Every break-glass entry is logged at creation time with the requesting operator, the incident reference, the allowed destinations, and the expiration. Every request that uses a break-glass entry is logged with the entry identifier, so the post-incident review can reconstruct exactly what was reached during the incident window. Break-glass entries that expire without being used are also logged, because their non-use is itself a signal about whether the operator's risk model matched reality.

Bottom Line

Network egress is the most concrete expression of an agent's actual reach into the world. An agent that can call any URL has not been bounded; an agent whose reachable destinations match exactly its pact-declared scope has been bounded in the only way that survives compromise. Default-deny is the only posture that makes the bounding real. Pact-derived allowances are the only mechanism that keeps the policy aligned with the agent's stated job over time. Audit-side-channel logging converts every policy decision into a verifiable event. Drift detection keeps the policy honest as the agent and its world evolve. Build the proxy first, derive the allowlists from pact scope, log every decision to a place the agent cannot reach, and treat denial spikes as primary signals of compromise. Done in this order, network egress stops being a firewall problem and becomes a behavioral guarantee.