How AIGQLUnify sits in your estate

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-based gating: 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:

• At the control plane gateway: handlers call enforcePdp first. If the decision is not allowed, the request ends with 403 Forbidden before any business logic runs. 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. Observability & auditability

Helpers like tagPdpDecision and tagDsarSpan attach the decision (allow flag, reason, resource, obligations) as attributes on every OpenTelemetry span. That gives you an immutable, queryable audit trail that ties every API call to the policy that governed it.

Most stacks have to bolt this together across gateways, microservices, and ad-hoc filters. AIGQLUnify ships it as one runtime.

A. Non-federated API gateways

• Typical pattern: JWT / scope checks in a Lambda authorizer, field-level PII handling buried inside each backend service.
• AI risk: LLMs see raw data and rely on prompt-level “please don’t leak PII”.
• AIGQLUnify difference: centralized PDP, obligations-driven masking at the GraphQL layer, and policy checks before AI is even invoked.

B. Traditional GraphQL federation

• Typical pattern: each subgraph owns its own auth; security is scattered across dozens of services.
• Failure mode: one service forgets to scrub a PII field and the composed graph happily returns it.
• AIGQLUnify difference: a single PDP decision for the whole federated query, enforced consistently via obligations across all backing services.

The result: Zero-Trust by construction — GraphQL, DSAR, and AI all share the same PDP/PEP path, the same obligations, and the same OpenTelemetry evidence.