From pain to proof

Why a Federated, Cyber-Resilient SaaS

From pain to proof: five classic failure modes of “glue code.” AIGQLUnify collapses them into a single governed, observable runtime. Below are runnable cURL playbooks and two example drifts that cost teams real money.

Open runbooks Policy Drift Version Drift Common failure modes

Live-ish cURL runbooks

PDP decision (role → obligations)

# Replace host/ids/roles as needed
curl -sS -X POST https://<cp-host>/pdp/decision.v2 \
  -H "content-type: application/json" \
  -d '{
    "tenant":"t_demo",
    "workspace":"ws_primary",
    "action":"read",
    "resource":{"type":"GraphQuery","name":"orders"},
    "context":{"role":"analyst","selection":["orders.id","orders.total","orders.userEmail"]}
  }' | jq

Shows allow, allowFields, mask, and feature flags (e.g., ai:false).

GraphQL with policy in-path

curl -sS https://<dp-host>/graphql \
  -H "content-type: application/json" \
  -H "x-tenant-id: t_demo" \
  -H "x-workspace-id: ws_primary" \
  -H "authorization: Bearer <jwt>" \
  -d '{"query":"query { orders { id total userEmail } }"}' | jq

Email should be redacted or omitted based on PDP obligations.

DSAR export lifecycle

# Create export
curl -sS -X POST https://<cp-host>/compliance/t_demo/ws_primary/dsar \
  -H "content-type: application/json" \
  -d '{"type":"export","subjectId":"user:123"}' | jq

# List requests
curl -sS https://<cp-host>/compliance/t_demo/ws_primary/dsar | jq

# Download artifact (when ready)
curl -L https://<cp-host>/compliance/t_demo/ws_primary/dsar/<id>/artifact -o dsar.zip

Exports are queued, executed, and tracked, with artifacts available for download.

Policy Drift

“Policy lives in a wiki” is how drift starts. AIGQLUnify evaluates policy at resolve time, stamps decisions into spans, and gates AI features behind obligations. Same query, different answers by role/attrs/risk—recorded.

Reproduce in minutes

# Analyst vs Admin
curl -sS -X POST https://<cp-host>/pdp/decision.v2 \
  -H "content-type: application/json" \
  -d '{
    "tenant":"t_demo","workspace":"ws_primary",
    "action":"read","resource":{"type":"GraphQuery","name":"orders"},
    "context":{"role":"analyst","selection":["orders.id","orders.userEmail","orders.total"]}
  }' | jq

curl -sS -X POST https://<cp-host>/pdp/decision.v2 \
  -H "content-type: application/json" \
  -d '{
    "tenant":"t_demo","workspace":"ws_primary",
    "action":"read","resource":{"type":"GraphQuery","name":"orders"},
    "context":{"role":"admin","selection":["orders.id","orders.userEmail","orders.total"]}
  }' | jq

Compare allowFields, mask, and features.ai. Then hit /graphql to see the runtime effect.

Version Drift

Hand-rolled glue quietly diverges from specs. AIGQLUnify ingests OpenAPI, generates SDL, and publishes a versioned plan—so clients, policy, and telemetry speak the same shape. Diffs are explicit; roll forward/back safely.

Plan & SDL inspection

# List published plans
curl -sS https://<cp-host>/plans | jq

# Get specific plan + SDL etag
curl -sS https://<cp-host>/plans/plan_2025_11_15T02_12Z | jq

# Optional: compare SDLs client-side to flag breaking changes

Surface diffs before they break consumers; keep PDP bound to the same versioned shape.

Common failure modes → runtime proof

The “glue” around your APIs tends to fail in the same ways. AIGQLUnify doesn’t just add another gateway — it replaces four recurring patterns with a single, governed runtime.

1) API sprawl killed velocity

Every new client meant another hand-rolled adapter: different auth headers, pagination quirks, partial responses. Over time, teams ended up debugging glue instead of shipping features.

Pattern: Each squad builds its own mini-gateway and data mappers.
Impact: Breaking changes everywhere, no shared plan, duplicated logic.
With AIGQLUnify: OpenAPI → SDL once per workspace, shared GraphQL plan, per-field policy.

2) Auth was fractured

One service spoke OAuth scopes, another SAML groups, a third IP allow-lists. “Who can see this field?” depended on the hop you hit first, not a single, auditable policy.

Pattern: Identity and policy rules hard-coded into each service.
Impact: Inconsistent outcomes by path; hard to prove least privilege.
With AIGQLUnify: PDP evaluates claims centrally, PEP masks/denies per field at resolve time.

3) Bolt-on security created blind spots

WAF rules, sidecars, and custom middlewares tried to “wrap” existing APIs, but new paths and params kept sneaking around them. Telemetry never showed what had actually been redacted.

Pattern: Security lives on the edge; data rules live in app code.
Impact: Gaps, drift, and no authoritative audit trail.
With AIGQLUnify: Security is in-path: decisions and masking are part of the query plan.

4) AI was tacked on at the edge

LLMs were wired “off to the side,” past the gateway and past the PDP. They saw raw payloads and sometimes cached them, making it impossible to prove what data fed which prompt.

Pattern: AI calls bypass the policy path and observability stack.
Impact: PII leakage risk, no DSAR story, no reproducible decision trail.
With AIGQLUnify: AI runs after masking & DSAR obligations, inside the same trace.