Google’s Gemini forum signals AI agent security is a distinct discipline

At a glance

What this is: Google’s Gemini Startup Forum positions AI agent security as a standalone discipline, with 33 startups grouped across six focus areas and eight vendors named in the agent security cohort.

Why it matters: This matters because IAM and security teams now have a hyperscaler signal that autonomous agent governance needs dedicated control patterns across discovery, runtime, and access visibility.

By the numbers:

• Google’s inaugural Gemini Startup Forum: Cybersecurity grouped 33 startups across six focus areas.

👉 Read Onyx's analysis of Google’s Gemini Startup Forum and AI agent security

Context

AI agent security is becoming a distinct control plane because autonomous systems can select tools, take actions, and complete work at runtime in ways that traditional application security does not model well. For IAM teams, the issue is no longer only who logged in, but what the agent can do after authentication and how that behaviour is governed across discovery, access, and audit.

Google’s decision to group AI agent security as its own cohort is a market signal, not a product claim. It suggests that enterprises standardising on Gemini, Vertex AI Agent Engine, or Google Workspace Studio will need identity and governance controls that track agent behaviour as a first-class security problem rather than an extension of appsec or human IAM.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do existing IAM controls struggle with autonomous AI agents?

A: Existing IAM controls were designed around human users and predictable workload behaviour. Autonomous agents can make repeated tool calls, chain permissions, and keep acting after the original task context changes. That creates lifecycle, privilege, and accountability gaps that traditional role models do not close on their own.

Q: What breaks when AI agents are treated like standard human users?

A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

Q: Who should own AI agent identity governance in an enterprise?

A: AI agent identity governance should sit jointly with IAM, platform security, and application owners because the risk crosses the runtime, the proxy, and the receiving service. No single team can see the whole delegation chain unless identity context is preserved end to end.

Technical breakdown

Why AI agent security needs its own control plane

Autonomous agents differ from ordinary automation because they can decide which tools to call, when to act, and how to sequence actions at runtime. That creates a governance problem that sits between identity, policy enforcement, and runtime telemetry. Discovery and posture tools need to identify the agent itself, the tools it can invoke, and the data paths it can traverse. Without that layer, security teams see activity only after an agent has already used granted access in ways that were not explicit at provisioning time.

Practical implication: Practitioners should treat AI agents as governed identities with runtime observability, not as passive software processes.

How runtime governance changes when agents can use tools dynamically

Runtime governance for agents must account for tool use, API calls, and workspace actions as part of the identity decision surface. That is different from static entitlement review, because the risk emerges from context-sensitive execution rather than from a single assigned role. In practice, governance has to follow the agent across SaaS, endpoints, and model surfaces, with logs that preserve the sequence of actions and the policy context around them. The control objective is not just access approval, but action containment.

Practical implication: Security teams need policy enforcement and audit trails that follow agent activity across every connected tool.

Why legacy IAM and appsec controls leave an agent gap

Legacy IAM assumes a human or workload with stable purpose and relatively predictable access needs, while application security tends to focus on code, vulnerabilities, and deployment boundaries. Autonomous agents blur those categories because they behave like identities, interact like applications, and operate with decision-making inside the session. That means the control boundary shifts from authentication alone to continuous behaviour governance. If the programme still treats agent access as just another application integration, it will miss the runtime decisions that create the real exposure.

Practical implication: Teams should reassess whether existing IAM, PAM, and appsec controls can observe agent intent and constrain agent execution in real time.

NHI Mgmt Group analysis

AI agent security is now a separate identity discipline, not an extension of application security. Google grouping agent security into its own cohort is a market acknowledgement that autonomous systems create identity behaviour that appsec does not fully capture. The core issue is not only model risk or endpoint risk, but governed access for actors that can choose tools and actions at runtime. Practitioners should expect this category to drive new identity patterns rather than cosmetic policy updates.

The control gap is runtime authority, not just initial access approval. Traditional IAM is strongest when access can be defined in advance and reviewed later. Autonomous agents weaken that assumption because they can decide what to do after access is granted, which makes post-hoc review an incomplete control. The implication is that identity programmes have to move from provisioning-centric thinking to action-centric governance.

Identity and agent security are converging around a new named concept: runtime governance gap. The runtime governance gap is the space between an approved identity and the actions it can autonomously take once live. That gap spans discovery, posture, tool usage, and audit, which is why agent security cannot be treated as a narrow feature set. Security leaders should view this as a programme design issue, not just a product selection issue.

Hyperscaler validation will accelerate consolidation in agent security tooling. When a platform owner groups agent security as a distinct discipline, buyers will start comparing discovery, posture, runtime monitoring, and governance as a cohesive control stack. That tends to compress the market around identity-centric workflows and expose point tools that cannot connect policy to execution. Practitioners should prepare for more integration demands and fewer excuses for blind spots.

Autonomous agent governance will force IAM, security engineering, and AI teams into the same operating model. The organisational boundary matters because the agent’s access touches identity policy, cloud telemetry, and model behaviour at once. No single team can own the full control chain without gaps. The practical conclusion is that agent governance must be run as a shared identity programme with clear accountability across the stack.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
• A further 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• For a deeper operating model, review OWASP Agentic AI Top 10 for the runtime risks most likely to surface in production.

What this signals

Runtime governance gap: agent security programmes will increasingly be measured by whether they can see actions as they happen, not just by whether they can approve access up front. That means discovery, telemetry, and control enforcement will need to sit in the same operational chain, especially where agents touch SaaS, endpoints, and workspace tools.

With 80% of organisations already reporting AI agents acting beyond intended scope, per AI Agents: The New Attack Surface report, the governance challenge is already operational rather than theoretical. Security teams should prepare for escalation in board-level questions about who owns agent behaviour and how it is audited.

The practical signal for programmes is simple: if an agent can use tools independently, your current identity review cadence may be too slow to matter. Teams should align agent governance with runtime monitoring and policy enforcement rather than assuming periodic review will close the gap.

For practitioners

• Map every AI agent to a governed identity record Inventory the agent, the owner, the connected tools, the data it can reach, and the environments where it operates. Keep the record aligned to discovery, approval, and audit processes so the agent is visible as a managed actor rather than an undocumented integration.
• Separate initial authorisation from runtime control Approve only the minimum tool set required at setup, then enforce policy checks during execution for sensitive actions, data access, and external calls. This prevents a one-time approval from becoming unrestricted runtime authority.
• Instrument tool usage and action sequencing across the agent path Collect logs for API calls, workspace actions, and endpoint activity in a format that preserves action order and policy context. Without sequence-level telemetry, investigations will miss how the agent reached the outcome.
• Revalidate IAM and PAM assumptions against autonomous behaviour Review where access reviews, least privilege, and step-up controls assume a human operator or a stable workflow. Replace any assumption that the actor will remain predictable with controls designed for decision-making at runtime.

Key takeaways

• Google’s cohorting of AI agent security confirms that autonomous agents now require their own identity governance model.
• The main control problem is runtime authority, because agents can change their action path after access is granted.
• Security teams should move from static approval thinking to continuous discovery, telemetry, and action-level governance.

Key terms

• Autonomous Agent: A software entity that can act with its own execution authority and use tools or data sources to complete tasks. In security terms, an autonomous agent is also a non-human identity, so its permissions, approval boundaries, and credential lifecycle must be governed like any other privileged workload.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Agent Security: The discipline of securing AI agents as identities with their own access, behaviour, and audit requirements. It combines discovery, access scoping, runtime monitoring, and governance so that the agent’s actions remain visible and constrained across the systems it can reach.

What's in the full article

Onyx's full blog post covers the operational detail this post intentionally leaves for the source:

• How Onyx maps Vertex AI Agent Engine, Gemini Enterprise, and Google Workspace Studio into its coverage model
• The specific working relationship implied by the Gemini Startup Forum cohort and Google Cloud engineering teams
• The product framing for discovery, posture, and runtime governance across autonomous agents
• The vendor's own description of how its control plane fits Google's AI surfaces

👉 The full Onyx post covers the cohort, the Google AI surfaces in scope, and the vendor’s own framing of agent governance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity strategy or maturing governance across human and non-human identities, it is worth exploring.