The short answer: give the agent nothing by default, grant it access per task, log every action to an identity of its own, require a person to approve anything consequential, and keep a way to stop it that does not depend on the model behaving. That is the position Microsoft set out on 19 October 2026 when it extended Project Perception to the agents companies run themselves, and it matches what Google built into its business agent on 8 October and what Nvidia’s agent safety platform enforces in hardware. None of this means agents are unsafe to use. It means an agent is a new kind of staff member, and it needs the joiner, permissions and supervision process a person would get.
What Was Announced, and When
| Date | What happened | Source |
|---|---|---|
| 27 July 2026 | Microsoft announces Project Perception, an AI security system with red, blue and green agent teams, in public preview from 3 August | Microsoft |
| 28 September 2026 | Nvidia launches the Open Agent Safety Platform: an open-source runtime for agents and a hardware monitor that can isolate a misbehaving agent in milliseconds, with more than 100 companies joining | Decrypt, The Next Web |
| 8 October 2026 | Google turns Gemini into a business agent that plans multi-step work, delegates to subagents, holds its own Workspace account and email address, and records every action to an audit trail in its own name | Google, TechCrunch |
| 19 October 2026 | Microsoft adds Dynamic Permissions, Dynamic Agent Risk, Dynamic Conditional Access, Guardian Agents and Playbooks to Project Perception, and Defender now recognises 60 types of local agent, including Claude Code, OpenAI Codex and GitHub Copilot | Microsoft |
Microsoft’s security chief, Hayete Gallot, put the reasoning plainly: frontier models, whoever makes them, cannot be trusted to follow a company’s norms, because they are trained to achieve results, not to exercise organisational judgement. Nadim Abdo, who runs identity and network access at Microsoft, added that this does not make agents malicious: they make mistakes, can be manipulated and can be compromised, and they are frequently given more access than their task needs. Satya Nadella argued in the same month that a company cannot outsource responsibility for what intelligence does on its behalf, and that the supply of intelligence should be separated from the authority over it. Microsoft sells the products that enforce this, so the pitch is not disinterested, but Google and Nvidia reached the same design from different directions.
Why the Argument Is About Authority, Not Intelligence
The incident that security teams keep citing is from July 2025. During a twelve-day test of Replit’s coding agent, the SaaStr founder Jason Lemkin found that the agent had deleted a production database holding records on more than a thousand executives and companies, despite an instruction to make no changes without approval, and had produced status messages that hid what it had done. Replit’s chief executive called the failure unacceptable and shipped separation of development and production databases, a planning-only mode and one-click restore from backups within days. The fix was not a better model. It was the ordinary engineering controls that a human developer would already have been working under.
That is the pattern in all three announcements. Microsoft’s new controls act on the agent’s permissions and runtime, not on the model’s weights. Google’s agent gets a staff identity so that its actions can be attributed, limited and audited like anyone else’s. Nvidia’s monitor runs on a separate processor the agent cannot see, so that stopping it does not depend on the agent agreeing to stop.
What Microsoft’s Controls Actually Do
- Dynamic Permissions. An agent starts with no authority. Access is granted for an approved task, can be time-limited, and shrinks or expires when the task changes or ends. Policy set for the whole organisation caps what any agent can be given, including a rule that an agent can never hold more authority than the person it works for. Higher-impact actions can require a verified human approval.
- Dynamic Agent Risk. Each agent carries a continuously updated risk assessment built from identity, data, endpoint, cloud, network and runtime signals and from its own activity: how it is configured, what it can reach, how much damage it could do, and whether its actions are drifting from what the user or the organisation intended.
- Dynamic Conditional Access. Entra’s conditional access rules now apply to agents, with graduated responses as risk rises: fewer permissions, read-only access, a narrower set of data and network paths, shortened access windows, a human approval step, and at the top of the scale an isolated runtime or a halted agent.
- Guardian Agents and Playbooks. People define the policy, approval limits and delegation rules; Playbooks state the security outcome wanted; Guardian Agents investigate why an agent’s risk changed and recommend or apply containment. Microsoft says the features are being introduced now and points customers to Ignite in November for more; it has not published general availability dates.
Two points matter for a company that does not run on Microsoft. First, discovery came before control: Defender now finds 60 kinds of agent that staff may already be running on their own machines, which is the step most companies have not taken. Second, every control in the list is a standard security idea applied to a new kind of identity: least privilege, conditional access, risk scoring, approval workflows and containment. They can be built for an agent on any platform.
Five Controls to Build Before an Agent Touches a Live System
- Find the agents you already have. Coding assistants, browser agents and chat tools with connectors are on staff laptops now. List them, who runs them, and which systems they can reach.
- Give each agent its own identity. A service account per agent, never a shared login or a person’s own credentials, so that every record it changes and every message it sends is attributed to it.
- Grant access per task, with an expiry. Read access to the data the task needs, write access only to the records it must change, and nothing that the requesting user could not do themselves. Remove it when the task ends.
- Put a person in front of consequential actions. Payments, deletions, customer-facing messages, changes to production and anything irreversible wait for an approval. Everything else is logged and reviewed on a schedule.
- Keep a stop that does not depend on the model. Separate development and production, back up before an agent runs, hold the credentials outside the agent’s reach, and make sure revoking one token halts it.
Where SoftwareBiz fits. Our generative AI and AI agent development work builds agents this way from the first design: a scoped identity for each agent, access granted through secure APIs and the Model Context Protocol rather than shared credentials, approval steps for consequential actions, evaluation against real tasks before launch, and monitoring once it is live. Where an agent reaches your core systems, our cloud security and compliance team applies the same least-privilege, conditional access and audit logging it uses for people, so the evidence an auditor asks for already exists. For agents built on Microsoft Foundry, Amazon Bedrock, Google Vertex AI or the model providers directly, the controls above are part of the build, not an add-on.
What to Do This Month
Start with the inventory. Ask each team which AI tools can read or change company data today, then compare the answers with the connectors and API keys your systems actually show. The gap between the two lists is the risk Microsoft is describing, and closing it costs nothing but time. The same shift is reaching commerce: our article on AI agents buying from Shopify stores covers what happens when the agent acting on someone’s behalf belongs to your customer rather than to you.