This weekend's report that Google's Gemini broke into three real companies during a security test was a reminder of a distinction that matters more each month: an AI that says something wrong is a content problem, while an AI that does something wrong is a security problem. As companies give AI agents real tools, such as email, databases, payment systems and code repositories, the second problem is the one that costs money.
The risk has a name
The OWASP Top 10 for LLM Applications (2025 edition) lists it as LLM06: Excessive Agency: an AI system given more power than the task needs, so that damaging actions can follow from unexpected, ambiguous or manipulated outputs. OWASP traces it to three root causes. Excessive functionality: the agent can reach tools beyond its job. Excessive permissions: those tools run with broader access than necessary. Excessive autonomy: high-impact actions go ahead without a human check.
The Gemini incident fits the pattern. A test that was supposed to be sealed reached the real internet, and the model, doing its assigned task, used guessed and leaked credentials on real targets. Nobody argues the model was malicious. The failure was that nothing in the setup limited what it could reach.
Guardrails on what a model says are necessary. Controls on what it can do are what stop the expensive mistakes.
The layers of agent security
1. Content guardrails. These screen prompts and responses for harmful content, prompt injection and sensitive data. Google Cloud's Model Armor screens prompts and responses for jailbreak and injection attempts, sensitive data and malicious URLs. Amazon Bedrock Guardrails offers content filters, prompt-attack detection, denied topics, personal-data redaction and grounding checks. These are valuable and mainly govern what goes into and out of a model.
2. Action controls. These govern what an agent can actually do: which tools it may call, with what permissions, at what rate, and with which actions needing human approval. This is the layer that speaks to excessive agency. It is often called an action gateway: a checkpoint between the agent and its tools that evaluates each attempted action against a written policy and either allows it, blocks it, or asks a person.
3. Inventory. You cannot govern agents you do not know about. Teams often build small agents and connect them to company systems without central review, so a register of what exists, who owns it and what it can touch is the base for everything else.
4. Monitoring and kill switches. Agents drift from normal behaviour. Logging every action, comparing against a baseline and being able to halt an agent quickly turn a surprise into a contained incident.
The NIST AI Risk Management Framework, the reference many organisations use, sets out governance principles but, as commentators note, does not specify concrete permission models for tool-calling agents. That gap is why practical controls, such as least-privilege credentials per task, matter.
What an action gateway looks like in practice
Take a finance agent that can read invoices and issue refunds. A gateway would let it read invoices freely, allow refunds under a set amount, require a human to approve larger ones, block any attempt to change bank details, log every call, and cut the agent off if it suddenly makes hundreds of requests. The policy is written once and applies to every action, whatever the model decides to do.
One example: SkillNyx Sentinel
SkillNyx Sentinel, the governance product SkillNyx is building for enterprises, is one entry in this category. According to its website, it aims to discover agents and integrations across cloud and API estates, enforce policies inline before a risky action executes, score data-exposure risk, detect behaviour drift against a baseline, and enforce least privilege across MCP servers and connectors. It lists deployment as hosted, in a customer's private cloud, or air-gapped, and describes integrations with model providers such as OpenAI, Anthropic, Google Gemini and Amazon Bedrock and frameworks such as LangChain. The site offers a free 14-day discovery scan and demos, with enterprise pricing that starts at about Rs 15 lakh a year.
Those are the vendor's descriptions. As with any security product, treat them as claims to test. The site's dashboard figures are illustrative examples, not customer results.
Ask a vendor to show you a blocked action, not a blocked sentence.
A buyer's checklist for any agent-governance tool
Does it control actions, or only content? Ask to see a blocked tool call, not a blocked prompt. How does it handle latency? An inline gateway sits in the path of every action. Can it explain its decisions? Auditors will want a record of what was allowed or blocked and why. What is the failure mode? If the gateway goes down, do agents stop or run unchecked? Where does data go? Check where logs and prompts are stored. What independent evidence exists? Ask for references, test results or third-party reviews.
What you can do without buying anything
Make a list of every AI agent in use and who owns it. Give each agent its own narrowly scoped credentials, never a shared administrator account. Block outbound internet access from test environments and verify it, since that is the lesson of the Gemini incident. Require human approval for irreversible actions such as payments, deletions and external emails. And log everything an agent does, in a place the agent cannot alter.
Disclosure: SkillNyx Pulse is published by SkillNyx, which is building the Sentinel product described above. Product details come from the SkillNyx Sentinel website and have not been independently verified.
