Policy by workload
Current policies distinguish workload key, environment, client mode, data class, model, risk signal, and signed attributes. Provider-region enforcement and approval workflow are still required.
For financial-services teams
Build toward model-risk and spend controls without overstating readiness.
The current baseline provides OIDC, built-in authorization, model policy, hard budgets, encrypted BYOK, reason-coded decisions, and hash-chained change metadata. It is not yet certified or validated for regulated production.
Implemented model, token, identity, and spend controls
Hash-chained configuration metadata without a tamper-proof claim
Current availability stated for approvals, SIEM, key management, and private deployment
In plain language
Connect model access to identity, limits, and a reviewable decision record.
The current baseline can constrain models, workloads, request cost, rate, and signed context while recording reason-coded outcomes. It does not replace model-risk management, vendor due diligence, approvals, recordkeeping policy, or regulated deployment validation.
The readiness outcomeA controlled pilot can prove enforcement and evidence behavior before any regulated workflow is authorized.
For the operating team
Map each workload to its approved operating envelope.
Model eligibility, user/workload identity, provider account, budget, environment, and evidence retention need named owners.
What administrators configure
Model boundary
Expose approved aliases and tested routes rather than unconstrained provider catalogs.
Execution context
Distinguish interactive, planning, CI/CD, and unattended agent activity using signed attributes.
Exception path
Define approval and evidence requirements outside the gateway until native workflow is implemented.
What happens to each request
- 01Classify
Use explicit workload and data-class context; never infer authorization from a model name alone.
- 02Restrict
Limit eligible providers, models, credentials, and telemetry before the request can leave the gateway.
- 03Operate
Run the tested rule in Observe, Shadow, or Enforce according to the approved rollout stage.
- 04Review
Retain metadata evidence and administrative change history for authorized operational review.
See the working control
See which rules can act and which are still observing.
Scope, action, rollout mode, and priority stay visible next to the dry-run decision simulator.
- Rendered by the real customer console and control API
- Exercised with safe OpenAI- and Anthropic-compatible simulators
- Sanitization gate rejects credential-shaped values and private owner email
Scope, action, rollout mode, and priority stay visible next to the dry-run decision simulator.
Control surface
Useful on day one. Explainable on day one hundred.
Each control has an operating path, an owner, and evidence that can be reviewed without collecting prompt bodies by default.
Evidence without prompt collection
Reason-coded decisions record which current control applied while gateway code avoids prompt persistence.
Operational integration
The API exposes evidence today; native SIEM, on-call, ticketing, and cloud-operations delivery are not currently included.
Evidence, not assertions
Preserve decision metadata without overstating immutability.
Hash-chained configuration metadata can reveal breaks in sequence; it is not described as a tamper-proof external archive.
Review security boundaries and current status- Reason-coded policy, route, retry, fallback, and denial metadata
- Bounded tool names, types, MCP hosts, and authorization outcomes—without schemas, arguments, or results
- Provider-reported usage reconciliation for complete responses and supported terminal streams
- Tenant-bound credential encryption and fail-closed tenant authorization
- Signed, retryable administrative audit delivery with payloads and configuration snapshots excluded
- Clear labels separating available controls from items that still require validation
Questions teams ask
Know the boundary before you deploy.
Clear answers for buyers, administrators, and security reviewers.
Is the platform ready for regulated production?
No general claim is made. A financial institution must complete its own risk, vendor, model, cybersecurity, resilience, recordkeeping, and legal review for the exact use.
Can an auditor see why a model was selected?
Current metadata records the requested model, selected target, applicable policy reasons, timing, configured estimate, and outcome for authorized review.
Does the platform provide approval workflows?
Native multi-party approvals are not yet shipped. Approval requirements must remain outside the gateway or be enforced through pre-established policy during a pilot.
Start safely
Start guided setupSee what the policy would do before it can block production.
Connect a provider credential, create a workload key, and begin in Observe mode. Move a tested rule to Enforce when your team is ready.