Agreement-scoped policy enforcement for cross-enterprise invocations

**Labels:** `feature-request`, `federation`, `security`, `discussion`

### Context

The gateway handles A2A routing and MCP proxying for agents within the same deployment. Rate limiting, access scoping, and audit logging exist for intra-org traffic.

### Problem

When an agent in Org A invokes an agent in Org B (cross-enterprise), three governance capabilities are needed:

1. **Outbound policy enforcement.** The gateway enforces policies on *inbound* requests (validating tokens, scoping access). For cross-enterprise, an equivalent enforcement point is needed on *outbound* calls — DLP scanning on request payloads leaving the org, budget checks before spending tokens on a partner's agent, and data-classification gates to prevent RESTRICTED data from crossing boundaries.
2. **Per-partner cost attribution.** Rate limiting exists (requests/min per caller/target), but cross-enterprise deployments need token-spend tracking, daily cost budgets, and per-partner usage attribution so orgs can answer "how much are we spending on calls to Partner X's agents this month?" and set hard caps.
3. **Agreement-scoped policy binding.** Policies today are per-user, per-group, or per-target. Cross-enterprise needs the ability to say "this policy applies specifically to traffic governed by this bilateral agreement" — enabling different enforcement rules for different federation partners.

### Why This Matters Now

- AI agent invocations incur real costs (LLM token spend). Cross-enterprise calls compound this — Partner B's agent may invoke expensive models that Party A pays for indirectly.
- Regulatory frameworks (PCI-DSS, HIPAA, GDPR) require demonstrating that sensitive data does not leave organizational boundaries without controls. Without outbound DLP, federation creates a compliance gap.
- Proprietary API gateways already provide gateway-level enforcement for their ecosystems. The OSS registry needs parity for cross-enterprise use cases.

### Open Questions

1. Should outbound enforcement be a separate proxy layer (like an egress gateway), or integrated into the existing nginx data plane?
2. Is a pluggable DLP interface (bring-your-own-scanner) the right approach, or should the registry ship a built-in regex PII detector as baseline?
3. How should cost attribution work when the registry doesn't control the target agent's LLM spend? (Estimate from token counts? Or require the partner to report back?)

### Prior Art

- API gateway usage plans (per-key throttling and quota) — a common pattern in API management platforms
- Envoy external authorization filter — pluggable policy evaluation on egress (open-source)
- OPA (Open Policy Agent) — declarative, context-aware policy evaluation decoupled from the data plane

No files, tests, or entry points are explicitly named. Start by locating the existing inbound policy, rate-limiting, and audit-logging implementation for intra-org calls, then trace where cross-enterprise MCP invocations are routed for outbound traffic. Follow that path to identify where an egress policy hook and agreement-scoped policy check could be inserted, and where per-partner usage/cost accounting is currently stored or calculated. Done means outbound DLP/budget checks and per-partner caps tied to agreement IDs are implemented and covered by targeted federation/policy tests or equivalent behavior docs.

Escrito por el modelo de indexación a partir del texto del issue.