epic: Centralized Policy Decision for Agent Platform Pipelines

Problem

Security enforcement in the agent platform is implemented as a pipeline of middleware plugins — each plugin independently inspects a request or response and may allow or deny it. While this model is composable and easy to extend, it has two structural weaknesses that undermine access control governance:

1. Decisions are made with incomplete information

Each plugin in a pipeline sees only the context it has collected itself. Once a plugin renders a verdict, the pipeline short-circuits — subsequent plugins never run, and the information they would have gathered never influences the decision. As a result, access control decisions are made with a partial view of the security-relevant signals available in the system. This creates exploitable gaps: a request that should be denied based on the combined signals of multiple plugins may be allowed because the deciding plugin acted before the full picture was assembled — for example, before a later plugin would have flagged the caller's identity as compromised or the target resource as sensitive.

2. Policy authority is fragmented across many decision points

Each plugin that can allow or deny a request is effectively a Policy Decision Point (PDP). A pipeline of N enforcing plugins is N PDPs operating sequentially, each with its own logic, configuration, and failure mode. There is no single place where policy is defined, audited, or reasoned about. This makes it difficult for operators to:

• Understand why a specific request was allowed or denied
• Ensure policy is consistent across all enforcement points
• Update policy without restructuring the pipeline

design

Apply the standard XACML/NIST model: PIP → PDP → PEP.

• PIP (Policy Information Point): Multiple plugins may serve as PIPs — each contributing attributes and security-relevant signals to a shared request context. PIP plugins do not make allow/deny decisions; they only enrich context.
• PDP (Policy Decision Point): A single plugin reads the fully enriched context and renders the final allow/deny verdict against the active policy. The platform pipeline contract must enforce that exactly one PDP plugin is active in any deployed pipeline. The system may support multiple PDP implementations to allow for technology choice or migration, but deploying more than one simultaneously is a misconfiguration.
• PEP (Policy Enforcement Point): The pipeline itself acts as the PEP — it guarantees that the PDP verdict is the sole basis for allowing or denying the request, and that no PIP plugin can short-circuit this flow.

The shared context that PIPs write to and the PDP reads from must have a defined schema — this schema is a required deliverable of this epic and a dependency for any PDP or PIP implementation built against it.

Goals and non-goals

Out of Scope

This epic covers the pipeline contract and architectural roles. It does not cover the implementation of any specific PDP policy language, PIP plugin, or the content of the shared context schema beyond its structure.

Success criteria

• A request is never allowed or denied before all PIP plugins have run and contributed to the shared context.
• There is exactly one active PDP plugin per deployed pipeline; the platform rejects configurations with zero or more than one.
• An operator can answer "why was this request denied?" by inspecting a single decision log from the PDP, without tracing through individual plugin logs.
• Policy changes require updating only the PDP configuration — not the pipeline structure or plugin order.

Stories to be associated with this epic

No response

Additional Context

No response