APL on CPEX Documentation

Effects & Sequencing

Mon, 01 Jan 0001 00:00:00 +0000

Effects and Sequencing#

An APL rule does something. That something is an effect. Effects are the building blocks of policy: a policy: block is an ordered list of them, and they run in sequence until one denies.

The effects#

Effect	What it does
`allow`	No-op. Continue to the next effect.
`deny` / `deny('reason')` / `deny('reason', 'code')`	Halt the phase and all later phases with a violation.
`plugin(name)` (alias `run(name)`)	Invoke a registered plugin (PII scan, audit log, custom check).
`delegate(name, ...)`	Mint a downstream credential via a delegator plugin. See Delegation.
`taint(label[, scope])`	Attach a label to the session or message. See Session Tainting.
field pipelines	Validate or transform `args`/`result` fields. See APL.
PDP call (`cedar:`, `cel:`, `opa(...)`)	Delegate the decision to a policy engine. See PDP Integration.

Sequencing and halt-on-deny#

Effects in a policy: block run top to bottom. The first deny halts the phase and skips every later phase, so order is a tool: put cheap gates first and expensive effects last.

PDP Integration

Mon, 01 Jan 0001 00:00:00 +0000

PDP Integration#

APL predicates handle attribute checks well: roles, permissions, scopes, comparisons. They are a poor fit for relationship questions (“is this user on the team that owns this repo?”) and for policy you already maintain in a dedicated engine. For those, APL hands the decision to a Policy Decision Point.

The requirement#

The scenario’s repository search must allow a read when the caller is an engineer and the repo is internal, or when the caller is on the security team, regardless of repo. That is a relationship-and-attribute decision over entities, which is exactly what an engine like Cedar exists to express. APL should make the coarse gate and let the engine make the fine-grained call.

Identity & IdP

Mon, 01 Jan 0001 00:00:00 +0000

Identity and IdP Integration#

Policy reads attributes: role.hr, perm.view_ssn, subject.id. Those attributes have to come from somewhere trustworthy. They come from identity resolution, which runs before policy and turns a verified credential into the attribute bag that predicates read.

The requirement#

The scenario authorizes with require(role.hr) and redacts with redact(!perm.view_ssn). For those to mean anything, CPEX must know, for each request, who the caller is and what roles and permissions they hold, established from a token the caller cannot forge, not from anything the LLM said.

Delegation

Mon, 01 Jan 0001 00:00:00 +0000

Delegation and Token Exchange#

When CPEX forwards an operation to a backend, the backend needs a credential. Forwarding the caller’s inbound token is usually wrong: it is scoped for the agent, not the backend, and it carries more privilege than the operation needs. Delegation mints a fresh, narrowly scoped credential for the specific downstream call.

The requirement#

The scenario’s get_compensation reads from a backend HR system that expects its own audience-scoped token with only the read_compensation scope. The caller never holds that token. CPEX must exchange the caller’s verified identity for a downstream credential, scoped down to exactly what the operation needs, and only after authorization has passed.

Session Tainting

Mon, 01 Jan 0001 00:00:00 +0000

Session Tainting and Information Flow#

Some controls cannot be decided from a single request. “Do not send anything externally after reading secret data” depends on what the session did earlier. CPEX tracks that history as taint labels: facts attached to a session that later policy can read. This is how CPEX enforces information-flow control, including write-down prevention.

The requirement#

A caller reads compensation data, then asks the agent to send an email. The email body is clean: no SSN, no salary, nothing sensitive in the text. It should still be blocked, because this session has handled secret data and an external send is a write-down. The LLM cannot be trusted to remember this or to refuse on its own, and a content scan of the email body would not catch it. The control has to live in state the model cannot see.