Agent identities are the new service accounts A developer built agent-off-switch (aos), an offline CLI tool that reads saved exports from Entra, AWS and GitHub to inventory non-human identities, rank findings by blast radius and provide an off switch for agent identities. The tool addresses the governance gap where AI agents act through service principals, managed identities, IAM roles and GitHub Apps that are often unowned and unre-certified, a risk OWASP categorizes as ASI03, Identity & Privilege Abuse. Part of my job is running access reviews. Human accounts are the easy part: there is an HR system, a manager, a leaver process. The hard part has always been the service accounts, and AI agents have made that part bigger. An agent does not act with its own authority. It acts with whatever identity it was given. In practice that is an Entra app registration or service principal, a managed identity, an AWS IAM role or an access key, a GitHub App installation or a deploy key. These are the service accounts we already struggle to govern, and agents add more of them, created faster, often by a team running a pilot rather than by the people who run identity. The pattern I keep seeing has three parts. Nobody owns the list. Nobody recertifies it. And when something goes wrong, nobody can stop one of these identities quickly and prove it is stopped. The OWASP Top 10 for Agentic Applications for 2026 https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ lists ASI03, Identity & Privilege Abuse, as its own category. The OWASP announcement https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/ describes leaked credentials letting agents operate "far beyond their intended scope". Whatever an agent is tricked into doing, the blast radius is set by its identity's grants. Microsoft says much the same in its governance guidance for agent identities https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview : agents have historically reached Microsoft services through tools that use service principals. Microsoft Entra Agent ID https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id is its answer, a dedicated identity type for agents built from agent identity blueprints, with Conditional Access, Identity Protection, governance and audit logs extended to them. It is a good direction. It does not cover the AWS role your coding agent assumes or the GitHub App it pushes with, and many agents in Entra still run as ordinary app registrations. These are the patterns I look for first in a review. Mail.ReadWrite works for every mailbox in the tenant with no signed-in user. If nobody owns the app registration, nobody will notice when it is misused, and nobody will answer the question "do we still need this?". Action: " " that a CI agent assumes through OIDC. on AWSRevokeOlderSessions policy keyed on aws:TokenIssueTime . If your off switch is "edit the trust policy", it is half a switch. None of these controls is new. They are the service account controls, applied to a population that grew while nobody was counting. I built agent-off-switch https://github.com/basitalisandhu/agent-off-switch aos for the reviews I run. It reads saved exports from Entra, AWS and GitHub, plus an optional agents.csv register, and works offline with no credentials of its own. Everything below is real output from the synthetic demo tenant that ships in the repository: the ids are fake and the AWS account is the documentation account 111122223333 . Inventory, owner, least privilege and credential hygiene come from aos review , which ranks findings by blast radius 0 to 100 and gives each a fix: bash $ aos review examples/demo-tenant --as-of 2026-10-09 Agent access review As of 2026-10-09: 13 non-human identities, 11 look like agents. 15 findings 8 error , ranked by blast radius 0 to 100, see docs/scoring.md . 4 agent identities nobody owns - coding-agent-runner aws-role:coding-agent-runner blast radius 100 : Action on Resource - switch off: aos off examples/demo-tenant aws-role:coding-agent-runner - repo-autopilot github-app:repo-autopilot blast radius 95 : administration: write on every repository settings, branch protection, deletion - switch off: aos off examples/demo-tenant github-app:repo-autopilot - mail-triage-agent entra:aaaaaaaa-0000-4000-8000-000000000001 blast radius 90 : Mail.ReadWrite as an application permission changes data for every user in the tenant - switch off: aos off examples/demo-tenant entra:aaaaaaaa-0000-4000-8000-000000000001 ... The findings table that follows covers the rest of the failure modes above, including a client secret 434 days old and a deploy key that can push, each with its fix. The same review can be written as SARIF for GitHub code scanning. aos inventory gives the full table of identities with owners, credentials, grants and last use, as Markdown, CSV or JSON. The off switch is aos off . It prints an ordered runbook and runs nothing. For the coding agent's role, the first two steps are the point I made above: stop new sessions, then revoke the ones already issued. bash $ aos off examples/demo-tenant aws-role:coding-agent-runner --as-of 2026-10-09 Off-switch runbook: coding-agent-runner Identity aws-role:coding-agent-runner aws-iam-role on aws . Owners: none recorded. Blast radius 100. Exports as of 2026-10-09. aos printed these commands and ran none of them. Run each change in order, then its verification, and keep the verification output for the incident record. Values in