Deny by default. Allow by design.

Field-level masking & actions in the APIGQL control plane UI. The same PDP decision that hides email for an analyst also denies the destructive Delete Order action.

DSAR export call traced via OpenTelemetry in Jaeger. A /compliance/.../dsar POST completes in ~1.5 ms with all HTTP and network tags attached for audit and SRE debugging.

How security works without killing latency

APIGQL keeps zero-trust and DSAR readiness in the path, but it’s designed so that PDP calls, masking, and OpenTelemetry add predictable, bounded overhead rather than surprise tax.

A. Policy decision logic (PDP)

The control plane acts as your Policy Decision Point via a decidePdp function that evaluates: subject (who is calling), action (read, create, delete, invoke for AI), resource (GraphQuery, DSAR, orders, etc.), and rich context such as the exact GraphQL selections requested.

• Deny-by-default: unmatched calls fall through to allow: false — a zero-trust baseline.
• Role- and attribute-based: analysts are blocked from create, delete, and introspection; DSAR actions are limited to admin / privacy roles.
• AI-aware policy: AI invocations are explicitly gated so, for example, isAnalyst && isAI can be refused up front.
• PII masking obligations: for an analyst’s read, the PDP returns obligations.mask = ["userEmail", …] instead of just allow: true.

B. Policy enforcement (PEP)

The same decision is enforced at two layers so you don’t have to re-implement security in every microservice:

• At the control plane gateway: handlers call enforcePdp first. If the decision is not allowed, the request ends with 403 Forbidden before any backend is touched. A global onRequest hook verifies JWTs when enabled.
• At the data plane: the obligations are sent alongside the request. The federated GraphQL engine uses obligations.mask to redact or drop fields as it resolves data — field-level PEP at the gateway / subgraph layer.

C. Performance & overhead (PDP + DSAR + OTEL)

Security is in the hot path, but the design keeps latency under control:

• Single PDP hop per request: the control plane runs close to the data plane (same cluster / region). Decisions are evaluated in-memory; there’s no per-field RPC storm.
• Masking in-process: once obligations are attached, masking is applied inside the GraphQL resolution pipeline. It’s string/field-level work inside the data plane, not another network call.
• DSAR is explicit, not “always on”: DSAR exports and deletes run via dedicated actions. Your everyday product traffic only pays for the PDP + masking step, not for full data exports.
• Streaming preserved: because masking happens as data is resolved, streaming / chunked responses can stay fast while still respecting policy.
• Feature-tunable: you can choose lighter policies for certain internal use cases while keeping full PDP, masking, and DSAR workflows at the edge or for regulated domains.

D. Observability & auditability

Observability is wired to the same decisions, without putting the collector on your critical path:

• Span tagging: helpers like tagPdpDecision and tagDsarSpan attach the decision (allow flag, reason, resource, obligations) as attributes on every OpenTelemetry span.
• Async export: spans are exported asynchronously to your collector (Jaeger, etc.); if the collector is slow or unavailable, queries still proceed.
• Compliance trail: you get an immutable, queryable audit trail that ties every API call and DSAR flow back to the policy that governed it — without bolting custom logging into every microservice.

Net effect: you get zero-trust by default, field-level masking, and DSAR-ready traces with a security cost that is designed to be small, predictable, and explainable to both your SREs and your auditors.