Product Workflow Evidence Security Access Dashboard Login Request Access
AI Infrastructure Control Plane

AI Infrastructure
Control Plane for
governed AI traffic.

Nizam Control sits between applications and AI providers, making attribution, policy posture, cost exposure, and audit-backed evidence visible before provider forwarding.

EDGE POLICY EVIDENCE PROVIDER
Control before provider forwarding

The control plane between
your app and the model.

Every AI request passes through Nizam before reaching a provider. Attribution, policy, and audit happen at the edge — not in the application.

01
Client App
Application sends request
Applications call the Nizam edge endpoint. One base URL change — no other client modifications required.
02
Nizam Edge
Control plane receives it
When applications route through Nizam Edge, every request enters the control plane before any provider sees it. Attribution and audit happen before forwarding.
03
Attribution & Policy
Workspace resolved, policy evaluated
The request is attributed to a workspace and API key. Operator policy signals are evaluated before forwarding.
04
Evidence Surface
Outcomes made visible
Policy outcomes, token attribution, and request context surface to the operator dashboard in real time.
05
AI Provider
Forwarded under operator control
Requests that clear policy evaluation are forwarded to the provider using server-side operator credentials.
Request Lifecycle

From ingress to audit — in sequence.

01 — Intercept
Edge receives the request
Client applications route to the Nizam edge instead of a provider directly. No client code change beyond a base URL swap.
02 — Attribute
Workspace and key resolved
The API key is resolved server-side to a workspace and operator. Usage is attributed before any further processing.
03 — Evaluate
Policy checked pre-dispatch
Operator-defined policy signals are evaluated against the request before the provider sees it. Budget limits and model controls apply here.
04 — Dispatch
Request forwarded to provider
Requests that clear policy evaluation are forwarded using operator-held server-side credentials. Client applications never hold provider keys.
05 — Audit
Record written to log
The complete record — request, policy outcome, response, token count, latency — is durably written to the audit log. Nothing is discarded.
Operator Visibility

The control plane, visible in real time.

Three surfaces expose attribution, policy posture, and governance evidence directly to operators. Nothing is inferred after the fact.

01 — Live Control Feed

Every request becomes visible.

Every AI request through the control plane is captured with model, status, latency, policy signal, and audit context — before provider forwarding and in real time.

  • request-level traffic visibility
  • status and policy signal surfacing
  • audit context before provider forwarding
Live Control Feed
Live request feed — AI traffic with workspace, model, token count, and policy signal
Savings Evidence
Savings evidence — estimated opportunities, observed exposure, and applied controls
02 — Savings Evidence

Estimated, observed, and applied — clearly separated.

Estimated opportunities, observed cost exposure, applied policy controls, and audit-backed evidence are kept distinct. Nothing is blended into a single claimed figure.

  • estimated vs applied vs verified separation
  • observed optimization opportunities
  • evidence-backed review context
03 — Client API Keys

Provider credentials stay server-side.

Client apps authenticate through scoped Nizam API keys. Provider credentials are resolved server-side and are never forwarded to clients or returned in any response.

  • client authentication through Nizam keys
  • provider credentials resolved server-side
  • request attribution by workspace and API key
Client API Keys
API key governance — workspace-scoped client keys with attribution and status
Governance Architecture

Infrastructure-level governance posture.

Isolation, credential secrecy, and audit integrity are enforced at the control plane level — not left to application logic or runtime assumptions.

Server-side provider credentials
Operator provider keys are stored and used server-side only. Client applications receive workspace-scoped Nizam keys. Provider credentials are never forwarded or returned in any API response.
Workspace policy posture
Each workspace carries its own policy posture — budget limits, model allow-lists, and content controls. Policy signals are evaluated at the edge before any request is dispatched to a provider.
Observe-by-default controls
All traffic is observed and logged by default. Workspace isolation ensures no request, key, or audit record crosses tenant boundaries regardless of traffic volume or shared infrastructure.
Audit-backed evidence
Every policy outcome is written atomically to the audit log at the time it occurs. Logs are not derived, reconstructed, or backfilled. Evidence is available for review immediately after each request.
Who uses Nizam Control

Built for operators who own AI infrastructure.

CTO / VP Engineering
Governance before AI reaches production.

You need attribution, policy posture, and an audit trail across every AI workflow before it becomes a cost or compliance exposure.

  • workspace-level cost attribution
  • policy posture before provider forwarding
  • operator-visible audit evidence
AI Platform / Infrastructure Team
A control layer the platform team owns.

You're the team that owns provider access, API keys, and the internal AI platform. Nizam gives you a server-side control plane without rebuilding it from scratch.

  • centralized API key and credential management
  • request-level observability across workspaces
  • policy signals without per-app instrumentation
Solo Technical Builder
Visibility and attribution from day one.

You're building AI-native products and want request attribution, cost visibility, and a policy layer before you scale — not after it becomes a problem.

  • per-workspace request and cost attribution
  • server-side key management from the start
  • audit-backed evidence as you scale
Controlled Access

Request access to Nizam Control.

No public self-serve. Companies and solo technical users request access. Each request is reviewed before activation.