Intelligence can go far.
Your boundaries stay.
Control belongs in the foundation, not in a prompt. FlozentAi connects every run to a trusted identity, a defined scope and an accountable execution path — and refuses, by design, to hold your credentials.
The four safeguards
Tenant isolation
Organization and host-tenant data stay inside explicit boundaries, enforced through PostgreSQL row-level security rather than by application code remembering to filter.
Approval before action
Review the exact proposal. Approve one execution, deny it, or let the decision expire. The approval is bound to that proposal — an edited proposal needs a new one.
A trace you can follow
Inspect the path from identity and context to the model call, the policy decision and the tool execution, for every run.
Freedom to choose
Connect private or hosted models while keeping a consistent experience in your product. The governance layer does not depend on which model you picked.
FlozentAi never accepts a credential value
This is the constraint people try hardest to work around, so it is worth stating plainly: there is no field in the console that takes a password, a token or a key. A connection stores a secret:// reference to a secret held in your own vault. The runtime resolves that reference inside the execution layer, after the policy decision, and the value never reaches the model, the console or the run trace.
If your vault is compromised, rotating the secret fixes every connection pointing at it without touching FlozentAi. If FlozentAi were compromised, the attacker would hold references to secrets they cannot read.
What goes in your vault, per method
| Credential format | What you store under the reference |
|---|---|
| OAuth 2.0 / OIDC | The access and refresh tokens your provider issued. |
| API key | The API key string the provider gave you. |
| Personal access token | The token a person generated in the provider. |
| Service account | The key file or JSON the provider issued. |
| Username and password | Both values, stored together under one reference in whatever shape your executor reads. |
Stopping things quickly
Governance that only works when everything is calm is not governance. Kill switches stop new runs at the level you choose without a deployment, approvals expire rather than sitting open indefinitely, and runs carry bounded execution budgets so a loop costs you a budget rather than an invoice.
- Stop new runs for an environment, an application or a single deployment.
- Unpublish an action and it stops being callable, including mid-flight proposals.
- Revoke a connection and every deployment using it fails closed rather than falling back to an older credential.
Bring it to your security reviewer.
The documentation describes the identity model, the approval binding and the isolation boundary in the detail a review needs.