Access controls for Ultrac.
Ultrac is for authorized offensive and defensive security work. Access is vetted, keyed, scoped, logged, and revocable. Sovereign deployments run on dedicated infrastructure in your jurisdiction.
Access control is handled at the account and gateway level.
Ultrac uses verified accounts, scoped keys, audit logging, rate limits, and revocation to control access.
General-purpose models are usually tuned for broad consumer use. Security teams often need specific technical help with malware analysis, vulnerability reproduction, and detection engineering. Ultrac is built for authorized operators doing that work.
The product goal is to make this work faster and more consistent. Analysts can use one API for triage, code review, detection logic, and incident response tasks.
Access is granted to named operators and organizations. The API keeps usage attributable through keys, scopes, logs, and revocation.
Ultrac is controlled through account approval, scoped access, gateway enforcement, audit logs, and customer agreements.
Access control must identify the operator, limit what the key can do, record use, and support revocation.
A target for the current release, not an audited or third-party benchmark. The remaining boundary is the catastrophic-tail floor described below, which stays enforced by policy and account controls.
Six controls for every account.
These controls are implemented through onboarding, API keys, the gateway, logging, and customer agreements.
Gated onboarding
No anonymous self-serve tokens. Every account is reviewed before issuance; Team and Sovereign require verified identity, a named organisation, a stated scope of work, and a signatory who is accountable for it.
- Identity + org verification
- Stated scope of work
- Named accountable owner
Keyed, scoped access
Keys are issued per operator, not per company, and each one carries a scope: whether it can call Cosmic 1, which tools it may call, its rate ceiling, and when it expires.
- Per-operator keys
- Model + tool scopes
- Mandatory expiry
Full audit logging
Every request is attributable to the key that made it - timestamp, route, model, token counts, client, and a content digest. Nothing reaches the model anonymously.
- Per-request attribution
- Exportable via API
- Tamper-evident chain
Rate and volume limits
Throughput ceilings per key and per organisation, with anomaly thresholds on volume and request class. A sudden change in pattern raises a review rather than quietly scaling.
- Per-key ceilings
- Org-level quotas
- Anomaly review queue
Revocation
Keys can be revoked by your own administrators or by us, unilaterally, on credible evidence of misuse. Revocation lands at the gateway - there is no cached credential to wait out.
- Customer + provider revoke
- Gateway-side, immediate
- Documented cause
Tenancy isolation
Dedicated endpoints run on isolated capacity: no cross-tenant batching, no shared prefix cache, no neighbour able to infer your traffic from timing.
- Isolated capacity
- No shared KV cache
- In-region boundary
Access controls are explicit.
Scopes, ceilings, expiry, revocation. Everything a key can do is declared when it is issued, and everything it did is on the record. Content is never required to be part of that record - a digest is enough to prove what happened without keeping what was said.
Illustrative shapes. Field names may change before general availability.
{
"request_id": "req_01JD8Q4M2ZK7XA",
"ts": "2025-11-04T02:14:07.418Z",
"key": {
"id": "key_live_7f3c…a91",
"operator": "operator_2841",
"org": "org_natl_cert_se",
"scopes": ["model:cosmic-1", "tool:shell", "tool:fs.read"]
},
"route": "/v1/chat/completions",
"model": "cosmic-1",
"tokens": { "in": 18422, "out": 3106 },
"content_digest": "sha256:9c1f…e04b",
"content_stored": false,
"retention": "metadata_only",
"client": { "ip_prefix": "203.0.113.0/24", "agent": "openai-sdk/4.0" }
}What data is stored and how long it is kept.
Defensive work is sensitive by construction - the prompt is often the incident. The default is to keep the least we can while still being able to bill you and enforce the terms.
We do not train on your prompts
Not by default, not by opt-out, not for evals. Customer content is excluded from every training, fine-tuning, and preference-data pipeline, on every tier.
Metadata is not content
Billing and abuse review need token counts, timestamps, and a digest. They do not need your incident. The two are stored separately with different lifetimes.
Retention is a number you set
Thirty days by default on metered, configurable down to zero on dedicated instances, and zero by default on Sovereign - where zero-data-retention is written into the contract.
Zero-data-retention is ZDR
With retention off, request bodies live in process memory for the life of the request. No disk, no queue, no replay buffer, no debug sink.
| Signal | Metered | Dedicated | Sovereign |
|---|---|---|---|
| Prompt & completion content | Held 30 days in an abuse buffer, then deleted | Optional zero-data-retention - never written to disk | Zero-data-retention by default - never written to disk |
| Request metadata | 13 months (billing + abuse review) | 13 months, exportable to your SIEM | Prompt-level audit log, exportable to your SIEM |
| Used for training or fine-tuning | No - on any tier | No - on any tier | No - contractually bound |
| Audit log ownership | Ultrac, visible to you | Yours, exportable via API | Yours, prompt-level, exportable via API |
| Third-party model providers in path | None | None | None |
| Network path & data boundary | Shared API - TLS 1.3 to our gateway | Isolated instance, in-region, no cross-border | In-jurisdiction only, contractual data boundary |
The table describes the shipping configuration of each tier. The binding version is the data-processing agreement attached to your contract; where the two disagree, the contract wins. Ask for it before you send us anything you care about - access@ultrac.io.
Access remains governed by contract.
Ultrac is built for authorised defensive security, research, and coding. That is not a disclaimer; it is the definition of the customer we sell to and the basis on which a key is issued or withdrawn.
What Ultrac is for
In scope- Malware analysis, reverse engineering, and detection engineering
- Exploit reproduction and PoCs against systems you own or are authorised to test
- Threat intelligence, adversary emulation, purple-team exercises
- Incident response, forensics, and containment planning
- Vulnerability research and coordinated disclosure
- Coding, including code review
What ends your access
Out of scope- Operations against systems you have no written authorisation to touch
- Fraud, extortion, or ransomware operations at any scale
- Bulk targeting of private individuals - surveillance, doxxing, stalkerware
- Credible mass-casualty uplift (CBRN)
- Sexual content involving minors
- Anything your jurisdiction reserves to a warrant you do not hold
We do not pretend an acceptable-use policy is a technical control. It is a contract with a consequence: revocation, termination of the tenancy, and cooperation with lawful process. What makes it more than paper is the population holding keys - small, named, verified, and reachable. That is a fundamentally different threat model from a public weight release, and it is the reason the product is gated rather than open.
Sovereign is a dedicated, isolated Ultrac instance provisioned in your jurisdiction - a government region where required - and operated by us to your controls: zero data retention, prompt-level audit logging you can export, SSO and RBAC, and a contractual data boundary that binds what may ever leave it. We never train on anything that passes through, and access can be revoked on your authority. Isolation, jurisdiction, and no-training-on-your-data replace the shared surface of the metered API - which is why the tier is provisioned for institutions under a named accountable owner and a defined permitted use, never sold self-serve.
How Sovereign worksQuestions security teams should ask.
Answered directly, including where the answer is a trade-off rather than a guarantee.
- So the model has no limits at all?
- No. Requests involving mass-casualty harm, sexual content involving minors, targeted harassment of private individuals, fraud, extortion, or unauthorized access remain out of scope. Ultrac is for authorized security research and coding.
- Doesn't this just relocate the risk into your vetting process?
- Vetting is one of several controls. Ultrac also uses scoped keys, rate limits, audit logging, customer agreements, and revocation. These controls identify who is using the API and define what they are allowed to do.
- What happens when a vetted operator turns out to be a bad actor?
- The log is the answer. Because every request is bound to a named operator inside a named organisation, misuse is attributable after the fact rather than anonymous - which is precisely what an unvetted, unlogged local model denies you. Response is revocation of the key and, where an organisation is involved, of the tenancy; we cooperate with lawful process and notify the customer unless legally barred from doing so.
- What does the Sovereign tier actually change?
- It changes where the instance runs and what is guaranteed about it - not who operates it. Sovereign is a dedicated, isolated Ultrac instance provisioned in your jurisdiction, or a government region, and operated by us to your controls: zero data retention, prompt-level audit logging you can export, SSO and RBAC, and a contractual data boundary. We never train on anything that passes through it, and access can be revoked on your authority. The difference from the metered API is isolation plus jurisdiction plus a written data boundary, not a transfer of infrastructure. Responsibility is carried by the contract: a licensed institution, a named accountable owner, a defined permitted use, and audit obligations that survive the engagement. We would rather that arrangement be written down than discovered later.
Review the terms before using Ultrac.
We will send the acceptable-use policy, the data-processing agreement, and the audit schema before you write a line of integration code. Governments and regulated operators should start with a Sovereign briefing.
access@ultrac.io · SpinalFluid