Permissions and roles around Jev decisions
Permissions around Jev belong to your IAM, not to a hidden TypeSafe RBAC API. Jev authenticates the caller service. Who may approve a transfer, see a trace, or override a hold is an application role. The model only fills typed slots — Choice options, Score values, Noul probabilities — that your code is already allowed to act on.
This page is for builders who already heard of Jev / System One and are wiring decisions into an existing org. jev.pro is an independent unofficial field guide — not affiliated with TypeSafe AI. We do not sell, issue, or proxy API keys. Confirm current API shapes on docs.typesafe.ai. Keys live in the TypeSafe dashboard after access, at console.typesafe.ai.
Steps
- Split four planes on a whiteboard before you ship: transport (service identity), decision (Jev), authorization (your app), review (humans). Write which system owns each verb.
- Authenticate the caller with one door. First-party HTTP sends
Authorization: Bearer. Official SDKs readTYPESAFE_API_KEY. A gateway door uses that gateway’s credential or OIDC — see authentication concepts. - Fetch human entitlements in your service before you build
state. Do not ask Jev “may user 12 approve this?” unless user 12’s already-fetched entitlements are instateas text you trust. The model is not your policy store. - Keep production keys off reviewers. Reviewers need a trace UI and reason codes, not the vault secret. Map that split in team onboarding and team roles.
- Gate irreversible options in application code. A Choice option named
admin_overrideis just another string unless your handler checks the actor. - Log traces to a channel that matches your least-privilege rules. Full
statein a Slack every intern can read is an access leak, not a model bug.
Pitfalls
- Inventing
/v1/roles. Public first-party routes remainPOST /v1/systemoneandGET /v1/models. Confirm on official docs; do not clone a rival IAM tree. - Treating a 401 as a permissions miss on the human. 401 is a bad or missing service key. Do not retry 401. Human “denied” is your 403 after you read the verdict.
- Shipping SSO through Jev. SSO is your IdP. Jev does not log customers in.
- Copying vendor throughput claims into an IAM design doc as if they were SLAs. TypeSafe’s models page currently claims 1,200 RPM and 250k tok/s; those can change and they do not grant extra roles.
- Letting one shared production key stand in for every environment. Scope secrets per env in your vault — API keys.
Split the planes
| Plane | Who | What |
|---|---|---|
| Transport | Service identity | Bearer key or gateway credential |
| Decision | Jev | Typed answers + distributions |
| Authorization | Your app | Can this actor take this verdict? |
| Review | Humans | Override reason codes |
Production code should fail closed when the actor is missing, even if Jev returned a high-confidence Choice. Schema-safe answers are not permission grants. If you need a human hold, implement the hold in your workflow engine and record why — Jev will not store your org chart.
Vercel AI Gateway’s model id typesafe-ai/jev is not a TypeSafe first-party alias. Do not assume Gateway OIDC implies TypeSafe org roles. Billing and identity stay on that door.
See also
FAQ
Does TypeSafe document org roles?
Use their console and legal pages. We will not clone a rival’s IAM tree or invent a roles API.
Should reviewers have the API key?
No. Reviewers need the trace UI, not production credentials.
Can Jev enforce SSO?
No. SSO is your IdP. Jev authenticates your service.
What this page does not claim
This page does not claim TypeSafe ships a hidden RBAC endpoint, that jev.pro can assign seats, or that a typed verdict is an authorization decision. It does not document official console org UI. Confirm product features on docs.typesafe.ai.
Disclaimer
This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai.