Skip to content
Sentinel AI Sentinel AI
Mesh demo Qila demo

Sentinel Platform

SENTINEL PLATFORM

Sharing a login doesn't scale, and passing keys around in chat is worse.

Sentinel Platform is where you get them back.

Open the Platform →

THE CONSOLE

When a whole team works off one account, nobody can say who’s allowed to spend what, whose key is live in production, or who may see the audit trail. Cap one runaway project and you cut off everyone. Off-board someone and their key keeps working. The moment more than one person touches the API, you’ve lost the controls you need.

It’s your console at /app — one place to hand out keys with their own limits, decide who can do what, and watch every request and every rupee. Everyone gets a role, every key gets a ceiling, and control is a screen you open, not a ticket you file.

The Sentinel Platform console One console at slash app, in two halves. Your builders get capped API keys, usage and spend, a sandbox to try prompts, the model list with rate caps, and docs. You, the operator, additionally control routing, upstream providers, pricing, guardrail defaults, governance and customer accounts — all live, so a change takes effect on the very next request rather than a redeploy. YOUR TEAM BUILDS ON IT API keys one each · capped Usage & spend every rupee, per key Sandbox try your prompts Models & limits catalog · rate caps Docs — quickstart and API reference YOU CONTROL IT · /app/admin Routing policy · where it goes Providers add · switch on/off Pricing rate · markup · FX Governance audit feed · posture Customer accounts — credits, quotas, markup, keys Sentinel Mesh — every control takes effect on the next request, not the next deploy
Two halves of one console: what your builders use to build, and what you use to run the gateway. Everything on the control side takes effect on the very next request — no redeploy, no waiting.

WHAT YOU GET

Keys you can cap or kill

give each project and person its own key with its own limits, so you can throttle or switch one off without touching the rest.

Spend you can see

usage per key and, on the pay-as-you-go cloud, your credit balance in PKR, top-ups on local rails, and a per-period statement showing cost, price, and margin by model.

A place to try before you ship

run the model on your own prompts, right in the browser.

Limits in the open

the live model list, per-key rate caps, and usage tiers.

Docs

a quick start and the full API reference.

WORKSPACES

Teams and workspaces

A Sentinel account is more than a single login — because a single login is the problem. Everyone gets their own workspace and can be invited into others, so an operator’s team, a client’s engineers, and your own staff can share billing and keys without sharing a password.

There are two roles, because a workspace only ever needs two answers: do you run it, or do you build on it?

Ownership is a safeguard, not a third role. Whoever created the workspace keeps an owner flag: they can’t be demoted or removed — not by another manager, not even by themselves — so a workspace can never be left with nobody in charge. Because it’s a safeguard, it’s not something you hand out from a dropdown.

The workspace you’re working in decides whose credits a request spends, so switching workspaces moves usage, keys, billing, and logs together. Access is checked on every request: remove someone and their access ends on their next call, not at their next login.

ACCESS CONTROL

Who can do what — decided by more than a title

A job title alone can’t answer the questions this product really gets asked. Can you cancel this key? depends on who created it. Can you read this audit trail? depends on whose traffic it covers. Can you manage this customer? depends on whose fleet they’re in. Answer any of those by title alone and you either give away too much or lock people out of their own work.

So every decision looks at three things together: who is asking (their role, ownership, tier, and whether they run the platform or a reseller fleet), what they want to do, and the exact thing they’re doing it to — all judged in one place. It gives back both the answer and the reason for it, and it defaults to no: anything it doesn’t recognise gets nothing.

How access is decided One rulebook weighs each request from three things: who is asking (role, ownership, tier, and whether they run the platform or a reseller fleet), what they want to do, and the exact item it acts on. It returns two answers: a verdict — yes or no with the reason, which defaults to no on anything it does not recognise; and the filter a list must apply — all, tenant, fleet, own, or none. The Settings page draws the same table by running this rulebook, so what is published cannot drift from what is enforced. Who is asking role · ownership · tier platform / reseller fleet What they want cancel a key · top up spend read the audit trail · … The exact item whose key · whose workspace whose fleet · demo or real WHO · WHAT · WHICH ITEM One rulebook weighs all three one item · whole list defaults to no A yes or no — with its reason "developer revoking their own key" "another workspace's audit trail" The filter a list applies all · tenant · fleet · own · none so a list can't show what a check would hide Settings → Roles & access draws this by running the rulebook — the published table can't drift from the enforced one.
One rulebook, two answers. One check decides a single item and tells you why; the other returns the filter a list must apply — so a list can never show rows a single-item check would have hidden. Both run off the very same rules.

THE RULES

These are the rules a plain job title can't capture:

  • A developer can cancel only the keys they created — so one developer can’t cut off another’s live traffic.
  • The defence customer sees their own audit trail because of what they bought, not their internal org chart — that record is part of the deal and can’t hinge on who reports to whom.
  • A reseller operator manages only the customers in their own fleet — never another reseller’s customers, and never the routing engine itself.
  • A demo reset touches only demo data — so it can never reach a real customer’s workspace.

The server checks these rules on every action, with the real thing in hand; what shows or hides in the menus is just for looks, never the actual guardrail. And Settings → Roles & access builds its table by running the same rules the server enforces — so what’s written down can never drift from what’s actually in force.

TWO ROLES

Manager vs Developer

RoleWhat they can do
ManagerRuns the workspace: members, spending, API keys, and all the monitoring.
DeveloperBuilds on it: their own keys, the Sandbox, Docs, Models, their own usage — and can see the balance.

OPERATORS

For operators: change the engine live

Run the gateway from /app/admin/engine — a live control panel, not a redeploy. Change a policy here and the very next request obeys it:

Routing

the default policy, timeout settings, and whether outside providers are in play.

Providers

add, key, turn on, or turn off upstream providers and their models; the router picks up the change on the next request.

Pricing

the sovereign wholesale rate, default markup, and exchange rate that set the metered PKR price.

Defaults & guardrails

the baseline blocked-terms list, starting credits and quota for new customers, and top-up limits.

Governance

the Sentinel Watch audit feed and your sovereignty posture.

Admin

for resellers: their customers, markup, credits, and keys.

DEPLOYMENT

One console, however you run Mesh

The Platform is the control panel for Sentinel Mesh no matter how you run it — the same keys, usage, models, roles, and governance whether you build on Sentinel’s in-country cloud, run Mesh on your own servers, or run the air-gapped Sentinel Qila defence build (isolated inside your perimeter — no outbound traffic allowed, so nothing ever leaves).

What changes between them is how you pay, not what you can see:

  • On the cloud, you pay per use — spend against prepaid credits, topped up on local rails.
  • On your own servers or with Qila, you pay one flat licence — the credit and top-up screens simply step aside, because there’s nothing per-use to settle.

Either way, your usage dashboards and Sentinel Watch stay right in front of you. A licence changes how you pay — never whether you can see what the gateway is doing.

Open the Platform

The Platform runs on the Sentinel Mesh gateway.

Open the Platform →