Mindset docsHow it worksSecurity and approval
Security and approval
The rules Mindset enforces for every agent with no setup, how write operations are approved, how credentials are kept and where your data goes.
Skills for your coding agent
Every agent runs under these rules, with nobody setting them up. With the settings your admins choose, they make up your org's compliance posture. If you write your own agent policy, list them as controls the platform enforces.
Why it matters#
No agent ships without these controls, and no agent can grant itself a write. A person, or a setting only an admin controls, decides which writes exist.
What Mindset enforces#
| Rule | What holds |
|---|---|
| Operations are the only way out | An agent, script or function reaches an outside system only through an operation on a connection. There's no general web or HTTP tool, so even a hijacked agent can reach only its operations |
| Writes need consent | Once per operation, from a person or the org setting. No agent can give it |
| Untested writes don't go live | Behavior tests refuse every write, and test runs write only what an admin agreed to. A script or function that calls an operation with no successful call since its last lapse can't go live unless an admin overrides it on the record. See the go-live gate |
| Every action is recorded | Mindset records each model call and operation call in the run's record, and each change in the audit record, so an agent can't skip either. The database refuses deletes from the audit record. See Runs and Audit and personal data |
| Environments can't see each other | An agent in Sandbox can't reach a connection in Production, and an API key works only in the environment it was issued into. See Environments |
Approving writes#
A write operation needs consent before anything can call it. It's given once per operation, never per call, and after that the write runs whenever an agent calls it. A read never needs consent.
| Consent | Meaning | Can an agent call it? |
|---|---|---|
| Not required | A read | Yes, once it's enabled, available and assigned |
| Pending | A write waiting for consent. The UI shows Needs your approval | No. A call is refused, not queued |
| Granted | A person, or the org setting, agreed to it | Yes |
An approval is recorded with the person's name and the time, and stops applying if the operation's definition changes.
Your org's default: On (auto-enable)
One org setting decides what happens to a new write: Turn on connections that change other systems automatically, under Settings → Systems. Only an org admin can change it.
| Setting | A new write operation |
|---|---|
| On (auto-enable), the default | Is granted as soon as it's registered, with no person involved |
| Off | Waits as Pending until a person approves it on the connection |
Withdrawing and disabling
| Button | On | What it does |
|---|---|---|
| Withdraw approval | An enabled write | Stops every caller. The operation goes back to Pending |
| Disable | An enabled read | Stops every caller until it's switched back on |
| Disable | A whole connection | Refuses every call to any of its operations before anything leaves |
Each takes effect on the next call, with no new agent version. Only a person can grant a withdrawn approval again.
An agent can never approve
Approving and withdrawing are on no agent's tools, and the server refuses an approval from anything but a signed-in admin, including an API key. An agent that registers a write gets a link to the approval screen to pass to an admin.
Consent can't say yes to one supplier query and no to another. For that, a script asks a person before the action and parks the run until they answer.
Live demoHelp widget · LedgerlyA billing help agent reads charges over MCP and stops at a refund nobody has approved.Credentials never reach the agent or the model#
A connection's credential is kept in a secret store and never put into an agent's context or sent to a model. A person enters it on a separate Enter a secret value form, and the model gets back only the field's name. A call aimed at a different host than the connection's is refused before the credential is looked up.
The outside system sees the connection's shared credential, so it can't tell which agent called. Mindset's audit names the agent. Scope each credential to what its operations need.
Where your data goes#
| Data | Where it goes |
|---|---|
| Your org's agents, conversations, runs and audit | The Mindset deployment your org lives on. Its region is fixed when the org is created |
| Model calls by your agents | The provider whose model key your org set: Anthropic, OpenAI or AWS Bedrock |
| Model calls by Orca and the builders | Platform-provided keys, unless an admin turns on Run the built-in agents on our own key |
| Model calls with AWS Bedrock | Your AWS account, in the region you name. Some models route across that region's geography, which can include other countries |
| Knowledge search embeddings | OpenAI text-embedding-3-large, on your own embedding key and endpoint if you set them, otherwise the deployment's |
| Outside systems | Only what an operation sends, to the connection's own host |
Personal data can be replaced with placeholders before it reaches the model provider (off by default). See Audit and personal data.
What Mindset doesn't enforce#
- Behavior tests before go-live. Saving and activating don't run them. See Test behavior.
- Cost caps or data residency on an AI model connection. Its limits are the size cap and personal data protection.
- Ownership and housekeeping. Owners, backups and archiving unused agents are your team's conventions. See Roll out Mindset.
Every org setting, with its default, is on Org settings. To approve or withdraw a write, see Approve what agents can do.