With agents, AI now sends emails, updates CRMs, merges code and posts in team chat, using permissions a person handed it. You can't fully inspect how a model reaches a decision, and its chain of thought doesn't reliably explain its behavior. Security teams have faced that problem with humans for decades, and many of the same controls apply to agents.
- The four rings used to govern a capable insider also apply to an agent: Model, Harness, Access and Audits.
- Agents on different model families can catch each other's mistakes, while humans review the risky changes.
- Sandboxed runs, placeholder credentials, egress allowlists and emergency brakes limit what a compromised model can access and where it can send data.
- A gateway scopes tools and data per role and logs every call outside the model's control, where the agent can read the record but never edit it.
On October 10, Satya Nadella published an essay, "Models as Insider Risks in the Super Intelligence Era," that puts a name to what we see every day. His argument is that the most capable models should be governed the way a company governs a trusted insider. Even without malicious intent, any capable actor with access to important systems can make mistakes or be compromised. The company that deploys an agent remains responsible for its actions.
The model should be contained from the start on the assumption that it may be compromised. Permissions, logs and the power to stop it must stay outside its control, so an authorized person can halt it mid-task. Visibility into a model's chain of thought is insufficient on its own, because no single model should control both its actions and the evidence used to judge them.
Nadella condenses this into seven rules: model diversity, observe everything, verifiability, independent controls, independent audits, containment, and incident disclosure. These follow the insider-risk practices security teams have used for decades: establish identity, limit privileges, log activity, set containment boundaries, and keep a kill switch.
An agent sits inside the same rings as an employee
A new hire brings their own judgment to the job and works within an office, where their badge opens only the doors they have access to. The company's swipe log records which doors they've gone through. The employee, the office, their badge, and the swipe log each have a counterpart for an agent.
The model
You can't fully inspect a model's decision process, and its outputs vary from one run to the next. Its explanations do not always reflect the actual causes of its behavior. We face similar limits with coworkers, which is why we have someone else review code before it ships or approve an expense before it is paid.
For agents, that reviewer should run on a different model family: Claude Code writes the code and Codex reviews it. Differences in their training can help each catch mistakes the other overlooks. For higher-risk changes, such as a database migration or a change to a security setting, the reviewer should be a human.
The harness
The harness is the agent's office: the environment it runs in, and the layer that lets you watch it and stop it. It does two jobs:
1. Observe. Hooks inspect each command, file read, download and tool call before it runs, and every model call is logged with the model and the cost. When something goes wrong, you review the session call by call.
2. Contain. The agent runs in a sandbox that uses credential brokering and an egress allowlist to restrict access. An emergency brake lets an authorized person stop the agent mid-task.
Authorization: $AGENT_TOKEN
agt_7Fq2…Access
Every call out of the sandbox passes through one of two gateways, where most of the governance controls sit.
The MCP gateway holds the real credentials, exposes tools by role and logs every call. It works per tool: an agent can read CRM records while delete_records stays off, or draft email while send_email stays off. The LLM gateway controls which models each team can use and how much it can spend, and logs the reasoning output those models expose.
- Tools by role, destructive ones off
- Holds the real credentials
- Logs every tool call
- Approved models per team
- Budgets per team
- Logs every model call
From “the wild west” to one connection per role
Without a gateway, early rollouts can become a mesh of connections between AI clients (ChatGPT, Claude Code, Cursor, Copilot) and systems (Salesforce, Jira, SharePoint, the internal database). Each connection has its own credentials and governance decisions, and API keys end up in employees' hands. A gateway brings those connections behind one SSO endpoint, with credentials, policy and logs in one place. The roles people already hold then apply to their agents.
Governance on data
Access controls also need to cover the data a tool returns. A new hire whose work requires three SharePoint sites should have access to just those sites. The gateway applies the same principle to agents, restricting them to specific sites, channels, folders and schemas, and masking regulated data as it is returned.
get_ticket AllowedFrom single-player to multiplayer AI
Most enterprise AI use is still single-player: one person, one chat window. Agents are now showing up in Slack and Teams as named coworkers that anyone in a channel can tag, with their own identity and permissions.
@Peter where are we on the Acme security review?
Two documents outstanding. I've chased their IT lead and will post the wrap at 5:35.
@Max can you prep me for the Acme call tomorrow?
On it. Brief will be in this thread 30 minutes before.
Static per-user permissions alone don't account for a shared conversation. For each request, the gateway must consider the channel where the agent is operating, who asked, and who else will see the response, then select a credential for each connector.
Some requests run as the requesting user, so that Slack, SharePoint or Salesforce enforce that person's own permissions. Others run under the agent's own read-only identity, for systems such as Sentry or a warehouse read replica. Neither approach uses a shared account, though teams are still working out how to apply these permissions in production.
Audit
The outermost ring records every call: which agent, who asked, in which room, which tool, what arguments, and which policy applied. The gateway writes the log outside the model's control, and the agent can only read it, just as an employee can't edit the swipe log. That separation keeps the model from changing the evidence used to audit its actions.
Where each control sits
The table below maps the controls to the four rings and shows where to start.
| Ring | Control | In practice | Order |
|---|---|---|---|
| Access | Independent controls | One governed connection per role, destructive tools off by default, one identity per agent | Start here |
| Audit | Observe everything | Every call traced by the gateway, written outside the model | Start here |
| Harness | Containment | Sandboxed runs with placeholder credentials, an egress allowlist and an emergency brake | Next |
| Model | Model diversity | Several model families check each other's work; humans review risky changes | Next |
| Access | Verifiability | Policies run in watch mode before they enforce, so you can see what they would block | Next |
| Access | Dynamic permissions | Scope set by channel, by who asked, and by who else can see the answer | At multiplayer |
| Audit | Incident disclosure | Share what failed and why | Ongoing |
If you don't yet have these controls, start with the MCP gateway. It provides one governed connection per role and keeps credentials out of employees' hands, while recording calls for the audit trail. Add sandboxing and model diversity as agents begin to interact with production systems. Dynamic, per-channel permissions come last in this sequence, when agents operate in shared spaces under their own identities.
About this post
Adapted from Jiquan Ngiam's keynote, "Insider Risk Controls for AI Agents," at the Cloud Security Alliance AI Security Summit 2026. The insider-risk framing is from Satya Nadella, "Models as Insider Risks in the Super Intelligence Era," October 2026.
About Mintive. Mintive builds governance infrastructure for the agentic enterprise: the MCP Gateway, the LLM Gateway, agent identities, Mint Guard for in-flight inspection, Agent Monitor for audit and SIEM export, and Coworker Agents for Slack and Teams. mintive.com · founders@mintive.com