Your rules, not one rulebook
A team dashboard and a customer portal do not carry the same risk. Your organisation sets how strict each check is, and where a person must review. Every organisation starts on Substrait’s default policy, then changes what it needs.
| You decide | What it means |
|---|---|
| Risk tiers | Your own tiers, and which signals put a change in each one |
| What blocks a release | Which findings stop a release, in your own classification |
| Severity and deadlines | Your own severity names, such as P0, and a response deadline for each |
| Human in the loop | Which changes need a person to review. Changes inside an approved boundary need none. |
| Sign-in | Your identity provider for every tool, and whether a production tool is public |
| Roles | Admin and app roles, built from a fixed list of permissions |
Safer than the usual routes
| The usual route | What goes wrong | On Substrait |
|---|---|---|
| Ban AI-built tools | People build anyway, on personal accounts, and it becomes shadow IT | A safe path people choose, because it is also the fastest |
| Review every change by hand | Reviewers fall behind, and builders route around them | Your policy approves clean changes on its own, and people review only what it flags |
| Let the AI builder’s vendor host the tool | Security never sees the code, or where the data goes | Every release is scanned, inside your own setup |
| Scan once at go-live | Every later change ships unchecked | Every promotion to production is checked, on the exact build |
| One fixed set of security settings for every tool | Too strict for a team dashboard, too loose for a customer portal | Your own tiers and rules, strict where the risk is |
What every release goes through
- Scanned. Substrait scans for leaked secrets across the code’s whole history, weak code, vulnerable dependencies, container issues, problems in the running tool, infrastructure definitions and malicious packages. A leaked secret must be rotated, not just deleted.
- Classified and documented. Substrait places each change in your risk tiers, with a written reason, and nothing a builder writes can lower the class. Each change then carries the paperwork its tier calls for: a change summary, a threat model, a risk analysis, a deployment plan, compliance tags and an API-change analysis.
- Fixed by the builder. A builder who is not an engineer fixes a finding with guided steps. A claimed false positive goes to your infosec team.
- Reviewed by people where it matters. A clean change is approved automatically. A change that is uncertain, high-risk or flagged by your policy goes to the right people to review, and nobody approves their own change.
- Recorded, then promoted. Every release gets a software bill of materials, a licence scan and a chain-of-custody record. Then the exact build tested in dev is promoted, and it can be rolled back in one click.
On the record
Substrait records every access, change, approval, grant and agent action.
- Who acted: the person, the tool, or the agent and the person it acted for.
- What happened: every deploy, promotion, approval, rollback, grant, withdrawal and read of company data.
- Nobody can alter it, a platform admin included.
- Searchable and exportable: filter it in the console, and export it to your security monitoring.
- Kept where you control it: the trail and the release records are written to storage your organisation owns.
One view of risk
- Every tool, in one registry, with an owner, a risk tier, its versions and a switch that stops it.
- Every finding, in one console, answering “how exposed are we right now?” in your own severity names, against your own deadlines.
When something goes wrong
Each of these takes effect at once.
| When | What you do | What happens, at once |
|---|---|---|
| A release goes wrong | Roll it back | The last good version is live again |
| A tool misbehaves | Switch the tool off | The tool stops |
| A tool should lose its data | Withdraw the data grant | The tool’s next call is refused |
| A guest should lose access | Revoke the sign-in link | Their session ends |
| An agent goes wrong | Switch off its identity | The agent stops |
Where data and secrets live
| Question | Answer |
|---|---|
| Where does our data live? | With the tool. Each tool’s database and its hosting sit together in one installation: your own cloud, or Substrait’s cloud. Each tool has its own database, apart from the platform’s data. |
| Who holds the credentials and keys? | Substrait holds each credential, encrypted and write-only, so builders and data owners never see one. Your organisation can manage its own encryption keys. |
| Whose AI model key is used? | Your organisation’s own. Substrait never sends your code or data to a model on credentials you do not hold. |
| What leaves our own cloud? | Status and decisions only. Policy and deployment instructions go in, data never comes out, and the connection is outbound from your side. |
Who can reach a tool
- Sign-in from the moment a tool exists. A new tool’s dev environment is born behind your organisation’s sign-in, through your identity provider.
- Dev stays closed. Turning sign-in off in dev needs a written reason and an operator’s approval, recorded against the tool.
- Production is the owner’s choice. A production tool has passed the security check, so its owner may make it public, as a customer-facing form must be.
- Guests by link. A person with no company account can be given one tool by a sign-in link. Withdrawing it ends their session at once.
- Delegated sign-in lists. An owner can let named people manage one tool’s sign-in list.