# 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.

**Skill for your coding agent:** [`mindset-human-in-the-loop/SKILL.md`](https://docs.mindset.ai/skills/mindset-human-in-the-loop/SKILL.md)

Builders work from a coding agent and operators from an AI client, both through the MCP server, or in the Studio. In Mindset, an agent is a prompt and a model, held to an order by a script when needed. It uses connections to outside systems, operations on them, functions and widgets. Every change is a version, and every execution is a run. Every piece sits on one security and compliance layer: the org sets its posture once, and every agent works under it, with the audit trail and, once an admin turns it on, personal data redaction. The platform runs in your own cloud (AWS, GCP or Azure) or is hosted by Mindset. Your app reaches agents through the SDK, your server through the API, and people through the Hub and schedules. Highlighted: Operation.

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](https://docs.mindset.ai/docs/compliance). 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](https://docs.mindset.ai/docs/connections-and-operations) 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](https://docs.mindset.ai/docs/versions-and-going-live#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](https://docs.mindset.ai/docs/runs) and [Audit and personal data](https://docs.mindset.ai/docs/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](https://docs.mindset.ai/docs/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](https://docs.mindset.ai/docs/scripts) asks a person before the action and parks the run until they answer.

**Live demo:** [Help widget](https://docs.mindset.ai/demos/widget). A 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.

> **Warning:** An MCP server's OAuth sign-in is one grant, shared by every run and user of the connection.

## 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](https://docs.mindset.ai/docs/audit-and-personal-data).

## What Mindset doesn't enforce

- **Behavior tests before go-live.** Saving and activating don't run them. See [Test behavior](https://docs.mindset.ai/docs/test-an-agents-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](https://docs.mindset.ai/docs/roll-out-mindset).

Every org setting, with its default, is on [Org settings](https://docs.mindset.ai/docs/org-settings). To approve or withdraw a write, see [Approve what agents can do](https://docs.mindset.ai/docs/approve-what-an-agent-can-do).
