AI agents are no longer limited to tools that security teams explicitly approve, buy, and deploy. A new report highlighted by The Hacker News points to a more difficult reality: many agents now arrive as embedded features inside SaaS products that companies already use. That makes them easy for the business to adopt, but hard for identity, security, and governance teams to see.

The practical issue is not simply that AI is being added to more applications. It is that agentic features can read context, make decisions, call connected systems, and sometimes take action across workflows. If those capabilities are introduced through a product update, a marketplace integration, or a user-level configuration, they may never pass through the same review process as a new enterprise application.

For CISOs and IT leaders, the message is clear: AI agent security should be treated as a third-party and non-human identity problem, not only as a model-risk problem.

Why SSO visibility is not enough

The Hacker News article cites environments studied for the 2026 State of Agent Security Report where roughly 1,280 third-party products contained AI capabilities, but only about 282 were behind single sign-on. That matters because many enterprise security programs still use SSO as the practical starting point for visibility and control.

If an application authenticates through SSO, security teams can often enforce access policy, monitor sign-ins, apply conditional access, and map usage to a human owner. But an embedded AI agent may operate inside a vendor platform, inherit permissions from a user, or rely on OAuth grants and API connections that are not obvious from the identity provider alone.

In other words, the absence of an SSO event does not mean the absence of an agent. It may only mean the agent entered through a path the identity stack was not designed to govern.

The agent risk is in the scaffolding

Much of the early AI security conversation focused on models: which model is used, whether prompts are inspected, how sensitive data is handled, and whether outputs are reliable. Those questions still matter, but they do not fully describe the risk created by agents.

An agent becomes dangerous or useful because of its scaffolding: the permissions it receives, the systems it can reach, the data it can read, the actions it can take, and the conditions under which it acts. A simple model connected to a code repository, ticketing system, CRM, and file store may create more enterprise risk than a more powerful model with no meaningful permissions.

That is why security teams should evaluate agents through four operational questions:

- Identity: Does the agent have a registered identity, owner, and purpose?
- Permissions: What can it read, write, approve, delete, export, or trigger?
- Connectivity: What systems can it reach directly, and what can it reach through chained integrations?
- Activity: What is it actually doing over time, and does that behavior match its stated purpose?

These questions move the review away from abstract AI concerns and toward measurable enterprise controls.

Inherited agents are the hardest to govern

Organizations usually understand how to review software they build themselves. They can scan repositories, enforce CI/CD checks, review secrets handling, and apply architecture standards. They can also review major SaaS purchases during procurement.

The more difficult category is inherited agents: AI capabilities added to existing platforms through feature releases or vendor roadmaps. These agents may be enabled by default, activated by individual users, or configured by department administrators outside central IT. They may also inherit permissions from the host application, which can make their effective reach much broader than expected.

This creates a supply-chain governance problem. The security team did not choose a new agent platform, but the organization still acquired agentic behavior through its vendors. That means vendor management, SaaS security posture management, identity governance, and data protection teams all need a shared view of embedded AI capabilities.

Practical controls to implement now

Enterprises do not need to wait for a perfect AI governance platform before reducing risk. A practical starting plan should include:

  1. Build an AI agent inventory. Track known agents, embedded AI features, automation tools, copilots, and third-party products with agentic capabilities. Include owner, business purpose, connected systems, and data categories.
  2. Map non-human identities and OAuth grants. Review service accounts, app integrations, delegated permissions, API tokens, and marketplace apps that can act on behalf of users.
  3. Require explicit ownership. Every agent or AI-enabled workflow should have a named business owner and technical owner. Unowned agents should not keep privileged access.
  4. Apply least privilege. Do not allow agents to inherit broad human permissions by default. Limit scopes, roles, repositories, channels, folders, and approval rights.
  5. Monitor behavior, not just configuration. Log agent actions in the systems they touch. Alert on unusual exports, permission changes, mass edits, new connections, or activity outside expected hours.
  6. Update vendor review questionnaires. Ask vendors whether their products include AI agents, what permissions they can inherit, how actions are logged, whether agent features can be disabled, and how customer data is used.
  7. Test incident response assumptions. Security teams should know how to suspend an agent, revoke its tokens, identify affected data, and reconstruct actions during an investigation.

What security leaders should ask vendors

For any SaaS product introducing agentic AI, procurement and security teams should ask direct questions:

- Can the customer disable the agent feature globally?
- Does the agent have its own identity in logs, or do actions appear only as the human user?
- Which permissions does the agent inherit from users, groups, roles, or connected applications?
- Can administrators restrict the data sources and destinations the agent can use?
- Are agent prompts, tool calls, decisions, and actions auditable?
- Does the vendor support retention controls, data residency, and customer-managed keys for agent-accessed data?

If a vendor cannot answer these questions clearly, the organization should treat the feature as an unmanaged automation risk until compensating controls are in place.

Bottom line

The rise of third-party AI agents changes the shape of enterprise risk. The biggest issue is not only whether an AI model is safe; it is whether the organization knows which agents exist, who owns them, what they can reach, and what they are doing.

Security teams that rely only on SSO, procurement review, or model scanning will miss a growing class of embedded agents. The better approach is continuous discovery of AI-enabled applications, non-human identities, permissions, connectivity, and runtime behavior. In agent security, visibility is the first control, and ownership is the second.

Source: The Hacker News