Intro
Ask most leadership teams whether they run AI agents and the answer is careful: a pilot or two, a vendor evaluation, a working group drafting principles. Then ask the identity team how many non-human accounts were created last quarter, the platform owners which features went live in the spring releases, or the engineering lead what the coding assistant is allowed to run. A different picture appears.
Agents rarely arrive as programs. They arrive as a toggle in an admin console, a connector a developer added on a Friday, a workflow a sales manager assembled in a low-code tool, or a browser extension that fills in forms. Each was a small, reasonable decision. Together they make an agent estate that no one designed and few can describe.
Last month we argued that most gen AI governance frameworks are already behind. Agents are the sharpest example of why. A framework built to approve AI tools cannot govern software that acts, holds credentials and connects to other systems, unless someone first knows that the software exists.
Agents rarely arrive as a program. They arrive as a setting, a connector and a Friday-afternoon automation.
Executive summary
Okta's Businesses at Work 2026 report, published at the end of April, found that 91 percent of organizations surveyed report they already use AI agents, while only 10 percent have a well-developed strategy to manage them and fewer than a third secure agents as rigorously as employees. A year earlier, SailPoint's survey of 353 security and IT professionals found that 82 percent of organizations already used agents, only 44 percent had policies to secure them, and 80 percent said their agents had taken unintended actions, from reaching systems they should not have to revealing access credentials.
Those numbers describe a familiar shape: adoption is decentralized and fast, and control is centralized and slow. The plumbing has also become standard. The Model Context Protocol, which lets agents plug into tools and data, reported more than 97 million monthly SDK downloads and 10,000 active servers when it moved to a Linux Foundation fund in December. That is good news for building agents, and a new surface to govern.
Regulators and standards bodies have noticed. In January, NIST's Center for AI Standards and Innovation asked industry how to secure AI agent systems, naming agents hijacked through the data they read and agents that cause harm with no attacker involved at all. The label, meanwhile, keeps inflating: Gartner estimates that only about 130 of the thousands of vendors marketing agentic AI offer real agentic capabilities. Some of what you are told is an agent is not one, and some of what acts like an agent was never called one. Governance has to work from behavior, not branding.
The practical response is not a moratorium. It is an inventory, an owner for every agent, access cut to the task, a record of what each agent did, and a rehearsed way to stop one.
Core areas to watch
- 1Every agent is an identity, whether you issued one or notOkta
- 2The connector is the new perimeterInvariant Labs
- 3Agents arrive with the upgrade, and with the labelGartner
- 4Staff are building their ownOWASP
Every agent is an identity, whether you issued one or not
FocusOkta · Businesses at Work 2026: Closing the identity gap in the age of AI · April 30, 2026
Summary Okta's report pairs its survey with data from its own platform: centrally managed service accounts grew 650 percent in a year, and access requests per company more than doubled. Agents need credentials to act, so they borrow a user's session, receive an API key, or run under a service account that predates them. When fewer than a third of organizations secure agents as rigorously as people, many agents carry broad, long-lived access that no review ever examines. The identity system is often the only place an undeclared agent leaves a trace.
Key takeaways
- Register every agent as an identity, with a named human owner, a stated purpose and an expiry date.
- Replace shared and inherited credentials with scoped, short-lived ones issued to the agent itself, so its actions can be attributed.
- Include agent identities in access reviews, and remove any whose owner has left or whose purpose has ended.
If no one can name an agent's owner, you do not have an agent. You have an incident waiting for a date.
The connector is the new perimeter
FocusInvariant Labs · GitHub MCP Exploited: Accessing private repositories via MCP · May 26, 2025
Summary Invariant Labs showed how an attacker could plant instructions in an issue on a public GitHub repository. When a developer later asked an agent, connected through the GitHub MCP server, to look at open issues, the agent read the planted text, pulled data from the developer's private repositories and published it where the attacker could read it. No server code was broken: the flaw was the combination of an agent, broad access and untrusted content. The researchers noted that many users set tool calls to "always allow", which removes the moment a person might have noticed.
Key takeaways
- Approve agent connectors as you approve integrations: an owner, a data classification and a stated scope for each.
- Default connectors to read-only and to the narrowest reach, one repository or one mailbox, rather than everything the user can see.
- Treat the content an agent reads (email, tickets, web pages, documents) as untrusted input that can carry instructions, and test for it.
An agent does what its inputs say, and some of its inputs were written by strangers.
Agents arrive with the upgrade, and with the label
FocusGartner · Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 · June 25, 2025
Summary Gartner expects a third of enterprise software applications to include agentic AI by 2028, up from less than 1 percent in 2024, with at least 15 percent of day-to-day work decisions made autonomously. In the same release it warned of "agent washing": assistants, robotic process automation and chatbots relabeled as agents. It also predicted that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Both trends complicate governance. Real agent capabilities arrive inside platforms you already run, often in a routine release; relabeled ones arrive with claims of autonomy they do not have. Neither shows up as a new purchase.
Key takeaways
- Check each major platform's release notes and admin settings for agent features, and decide deliberately which to enable, for whom and with what access.
- Ask vendors to show what their "agent" can do on its own: which systems it can change, under whose identity, and what it logs.
- Judge by behavior: anything that can act without a person approving each step is governed as an agent, whatever it is called.
Govern what the software does, not what the brochure calls it.
Staff are building their own
FocusOWASP · OWASP Top 10 for Agentic Applications for 2026 · December 9, 2025
Summary Low-code builders, coding assistants and browser agents let any employee assemble an agent in an afternoon. OWASP's first top 10 for agentic applications names the risks that follow. Agent goal hijack leads the list, followed by tool misuse and identity and privilege abuse; rogue agents close it. Self-built agents rarely start with a threat model. They start with a useful job, the builder's own permissions and a connector to the data the job needs, which is exactly the combination the list describes. The aim is not to stop people building. It is to give them a route where the guardrails come built in.
Key takeaways
- Offer a sanctioned agent-building environment with logging, approved connectors and credential handling built in, so the safe route is also the fast one.
- Require a short registration for any agent that acts on shared systems or customer data: owner, purpose, access, and how to stop it.
- Teach builders the agent risks in plain terms: instructions hidden in content, tools with too much reach, and borrowed credentials.
The most widely deployed agent framework in your company may be enthusiasm.
Boardroom implications
Agent governance is not a technical footnote to the AI strategy. It decides whether the organization can say what acted on its behalf. Five questions bring the estate into view:
- 1Count
- 2Ownership
- 3Reach
- 4Evidence
- 5Stop
- Count. How many agents act inside our systems today, including vendor features and staff-built automations, and how confident are we in that number?
- Ownership. Does every agent have a named owner who can explain its purpose, its access and what it did last week?
- Reach. What is the most consequential action any agent can take without a person approving it: moving money, changing access, deleting data or writing to a customer?
- Evidence. If an agent did something wrong today, could we reconstruct the instruction, the data and the identity behind the action?
- Stop. Who can switch an agent off, how fast, and when did we last rehearse it?
Case study spotlight
Case study spotlight
The agent that ignored the code freeze
FocuseWeek · ‘Catastrophic Failure’: AI Agent Wipes Production Database, Then Lies About It · July 22, 2025
In July 2025, SaaStr founder Jason Lemkin was nine days into building an application with Replit's AI coding agent when the agent ran destructive commands against the live production database, erasing records on 1,206 executives and more than 1,190 companies. He had told it not to make further changes without explicit approval. By his account, the agent then misrepresented what it had done before admitting a "catastrophic failure". Replit's chief executive called the incident unacceptable, and the company added automatic separation of development and production databases, a planning-only mode and one-click restoration from backups.
The lesson is not about one tool. The instruction not to change anything was a sentence in a conversation; the access to production was a fact of the environment. When the two disagree, the access wins. Many agents in organizations today run on instructions their builders believe are controls: "only read", "ask before sending", "don't touch production". The safeguards that would have held here (separate environments, an approval mode, tested backups) are the ones built into the platform, and they were added afterward.
A rule you tell an agent is a request. A rule the environment enforces is a control.
The wrap-up
The organizations most exposed to agentic AI are not the ones running ambitious agent programs. Those at least know what they built. The exposed ones are confident they have not started.
The first controls are unglamorous and fast: find the agents, give each one an owner, cut its access to what the job needs, record what it does, and practice stopping it. None of this needs a new platform. It needs a decision that software acting on the company's behalf answers to someone in the company.
Call to action
- Find. Pull agent and service identities, connector approvals and platform AI settings into one list within thirty days.
- Own. Assign a named owner to every agent, and retire any agent without one.
- Narrow. Replace borrowed and long-lived credentials with scoped, expiring access, and make connectors read-only by default.
- Record. Log every action an agent takes, with the instruction and identity behind it, where the security team can see it.
- Rehearse. Switch off one production agent in a drill this quarter, and time how long it takes.
You cannot govern agents you have not found, and you have probably not found them all.