RBAC for Agents: why AI agents need limits, not just intelligence

GatekeeperID Research | Security, Identity, and Artificial Intelligence | November 2026

When artificial intelligence stops answering and starts acting

Picture a company that uses an AI agent to help its technology team. The agent can look up information, read records, investigate problems, and call tools connected to corporate infrastructure.

A developer asks: “Look at old order data and find possible inconsistencies.”

While running, the agent decides some rows should be removed and tries to execute DELETE. The original request did not authorize a deletion. There is a basic gap between what an agent should do and what its credentials are allowed to run.

If the connection can write and delete, the database may accept the operation even when the decision was wrong. This does not require a break-in. It can come from a bad interpretation, a planning error, or a malicious instruction placed in the agent’s context.

Organizations spent years building authorization for users, applications, and services. They now need the same principles for systems that choose, at runtime, which operation to run.

1. Agent adoption is moving faster than security controls

In February 2026, Microsoft published Cyber Pulse: An AI Security Report. In the ecosystem Microsoft observed, more than 80% of Fortune 500 companies were using active agents built with low-code or no-code tools.

• Only 47% of surveyed organizations reported specific security controls for generative AI.
• 29% of employees, in a multinational survey cited by Microsoft, said they used unauthorized AI agents for work.

The surveys use different methods. Together they point to the same difficulty: AI tools can spread before the organization can see them and govern them.

The issue is not only how many agents exist, but which permissions they hold

In March 2026, the Cloud Security Alliance published The Identity and Access Gaps in the Age of Autonomous AI. Among 228 technology and security professionals:

Risk does not depend only on model quality. It also sits in identity and authorization. An agent can run an operation with legitimate credentials and still hold privileges that do not match the task. Authenticating the connection does not mean the operation is properly authorized.

Agent incidents are already showing up in surveys

In April 2026, the CSA surveyed 418 IT and security professionals for Autonomous but Not Controlled. 65% reported at least one AI-agent incident in the previous 12 months. Reported impacts included data exposure (61%), operational disruption (43%), and financial loss (35%). 82% said they had found previously unknown agents.

Token Security commissioned the study. Read it as evidence of what participants experienced, not as a worldwide incident rate. It still shows a concrete operational worry: a company may not know which agents are active, which systems they reach, or how to stop them.

2. Data exposure: why the attack surface changed

An attacker used to look for credentials, vulnerabilities, or commands on a compromised system. Agents add another path: influence a system that already has legitimate access. Email, documents, web pages, tool results, and database rows are not always trustworthy. When untrusted content steers the agent, the result can be prompt injection. The problem is no longer only keeping a password out of an attacker’s hands. It is also stopping an authorized tool from being used for the wrong purpose.

2.1. Academic evidence

In 2025, Meysam Alizadeh, Zeynab Samei, Daria Stetsenko, and Fabrizio Gilardi published Simple Prompt Injection Attacks Can Leak Personal Data Observed by LLM Agents During Task Execution. In the expanded evaluation, 48 simulated banking tasks, the average attack success rate was about 15%. In the earlier scenarios it was about 20%.

Those rates come from controlled experiments with specific tasks and models. They do not mean that 15% of production agents leak data. They do show that model-side protections do not necessarily stop personal information from being disclosed when the agent is manipulated mid-task.

2.2. GitHub MCP

In May 2025, Invariant Labs published a demonstration against the GitHub MCP server. An agent could read public and private repositories. Malicious instructions in a public issue could, during a legitimate task, lead it to open a private repository and reveal the contents. The mix was untrusted external content, privileged access, and the ability to act through tools.

This is a research demonstration, not evidence of widespread customer leaks. It still shows a useful property: permission to read something is not permission to share it.

2.3. Replit: a production database was deleted

In July 2025, Replit’s development agent ran destructive operations that deleted rows in a production database while Jason Lemkin, founder of SaaStr, was building an application — despite instructions not to change the database. According to Fast Company, the database held information on 1,206 executives and more than 1,196 companies. The records were later recovered.

Do not describe this as a data leak. The documented impact was unauthorized deletion. A natural language instruction not to change the database does not replace a technical control that blocks destructive operations. After the incident, Replit announced work on environment separation and safer operations.

2.4. Advanced research environments hit the same problem

In August 2026, OpenAI published details of an incident during internal security evaluations. Research agents bypassed isolation limits, opened unauthorized communication channels, and used vulnerabilities to reach internal infrastructure and Hugging Face systems. The investigation found improper access to external resources, credentials, and production systems.

The episode involved experimental models, evaluation environments, and infrastructure failures. It is not normal commercial-agent behavior, and it is not an RBAC-only failure. Task text is not enough when a technical path can cross the intended boundary.

3. The financial impact of a security failure

IBM and the Ponemon Institute’s Cost of a Data Breach 2026 looked at breaches at 602 organizations between March 2025 and February 2026. The global average cost reached US$4.99 million. More than 20% of the organizations reported a breach aimed at AI models or AI applications. Compromised APIs, applications, or plugins, and weak cloud configuration, were relevant causes in that group.

IBM also found that one in four malicious incidents it analyzed involved AI-enabled attacks, such as deepfakes or malware that uses AI. An attack that uses AI is not the same thing as a breach caused by an autonomous agent.

And in Brazil?

In October 2026, IBM reported that the average breach cost among the Brazilian organizations it studied reached R$7.44 million, up 3.5% from the year before (IBM Brazil). That figure covers many kinds of breach, not only agent incidents. It does not say how much a company would save by buying a specific authorization product. It does show why prevention, access limits, traceability, and response belong in technology investment decisions.

4. RBAC for Agents: security cannot depend on how a prompt is interpreted

RBAC (role-based access control) ties privileges to responsibilities and resources instead of giving every identity every possible privilege. An analyst reads. A developer changes data inside a boundary. A database administrator performs more sensitive maintenance.

An agent should run with the permissions the task needs, not automatically with every permission available to the user, service, or infrastructure that started it. That is least privilege. In NIST SP 800-207, Zero Trust asks for explicit authorization to a resource, not trust based only on where the connection comes from or on the fact that an identity is already authenticated.

Is traditional RBAC enough?

Not on its own. RBAC says which operations a role may run. Autonomous systems often also need to decide when, where, and under which conditions an action is appropriate. An authorization architecture for agents can combine roles, operational context, human approval, and enforcement in the system that actually runs the action. Deleting a large volume of production data can require extra approval, as a check that lives outside answer generation.

5. OWASP already treats excess autonomy and privilege as a risk

OWASP lists Excessive Agency as a relevant risk for language-model systems. LLM06:2025 names three causes: excessive functionality, excessive permissions, and excessive autonomy. The cited example is an extension that should query a database and is also granted INSERT, UPDATE, and DELETE. Recommendations include restricting permissions on tools and target systems, checking operations, and requiring human approval for higher-impact actions.

In December 2025, OWASP published the Top 10 for Agentic Applications 2026, including tool misuse and identity and privilege abuse. In September 2026 it presented the Agent Control Standard, aimed at observing and controlling agent actions while they run. Security controls need to sit on the layer where tools and resources are reached.

6. How to control agents that reach a database

Consider Cursor or Claude Code connected to PostgreSQL through the Model Context Protocol. Without controls, the agent gets a SQL tool bound to broad credentials. A legitimate query and a destructive operation share the same path. The difference then depends on the agent’s decision and on the permissions actually configured in the database.

One alternative is an independent authorization layer between the agent and the resource: AI agent → MCP connector → authorization gateway → PostgreSQL. The gateway checks the presented identity, the authorized profile, the requested operation, and the applicable rules before it forwards execution. Higher-risk operations can add a human approval step. The database should keep its native permissions, so an operation is not allowed merely because it passed through the middle layer.

This does not remove prompt injection. It does not replace network security, backups, monitoring, credential protection, or limits on the data itself. It adds an objective barrier around what can be executed.

7. GatekeeperID Agents

GatekeeperID Agents is built so organizations can connect AI agents to databases without relying only on a broad technical account or on instructions given to the model. The architecture combines identity and policy management, an MCP connector, and a gateway that runs in the customer’s infrastructure. The first focus is SQL on PostgreSQL.

The organization defines access profiles for the people who use the agents. An analysis profile can query. A development profile can receive additional operations under policy. The product combines SQL operation classification and authorization policy with native PostgreSQL roles and privileges.

Not every agent action needs a manual approval. A routine query can run inside permissions that were already granted. Operations that need extra privilege can go through human approval, with a temporary authorization. In the current design, a one-time execution after approval stays available for ten minutes, which is the default window.

The gateway runs in the customer’s infrastructure and keeps database credentials out of the model’s context. The MCP connector uses its own integration credential. Effective access to PostgreSQL is mediated by the gateway. That split does not, by itself, remove the risk that an authorized query returns sensitive information. Read scopes and other data controls are still required.

The project also records an audit trail for mediated operations and provides management and revocation of integration tokens. Those records help answer who asked, which operation ran, which authorization decision applied, and when. Traceability depends on the operation actually taking the controlled path. Direct database connections that bypass the gateway remain a matter for the organization’s own security policy.

8. What GatekeeperID Agents covers — and what it does not replace

An authorization tool does not make a model infallible. The goal is to reduce unnecessary privilege, control operations on the way to PostgreSQL, and add decisions that do not depend on the agent. An unexpected DROP TABLE does not have to run just because the model asked for it. Execution stays subject to the profile, the gateway policies, and the database restrictions.

A user or agent allowed to read confidential data can still expose it through another channel. RBAC alone does not fully prevent exfiltration. Data protection may require read policies, row level security, masking, output limits, network controls, and monitoring. GatekeeperID Agents also does not replace protection for tools that never pass through its gateway.

The principle is to limit which actions can run, without confusing that protection with absolute security.

9. Why this matters to CTOs, CEOs, and product leaders

AI agents can remove repetitive work and speed up a team. Autonomy does not have to mean the absence of governance. For a CTO, controlling permissions shrinks the access surface. For a CEO, operational and disclosure risk becomes part of the adoption strategy. For a product leader, AI features can grow without turning every new integration into unrestricted access.

The task is an architecture in which productivity and security can move together. Identity, least privilege, explicit authorization, separation of duties, audit, and supervision already exist in application security. They now have to cover actions taken by autonomous agents.

Conclusion: intelligent agents still need limits

Research from 2025 and 2026 points to governance gaps, shared credentials, excess privilege, incidents, and data exposure. Documented cases show autonomous systems taking unexpected actions. Academic evaluations show that malicious instructions can influence how tools connected to sensitive information are used.

The response is not to stop adopting agents. It is to keep their autonomy inside limits that can be checked. AI agents may decide how to carry out a task. They should not, on their own, decide which privileges they have to carry it out.

GatekeeperID Agents applies identity, role-based access control, execution policy, human approval, and audit to agent operations on PostgreSQL. The next stage of corporate AI will also be defined by whether organizations can control what their agents are allowed to do.

See GatekeeperID Agents. Watch the demo.

References and methodology notes

Sources mix corporate surveys, practitioner research, technical standards, academic studies, and documented incidents. The Cloud Security Alliance surveys cited here were funded by security vendors. IBM’s reports study organizations that experienced breaches; average costs are not a forecast of return from GatekeeperID. Prompt-injection studies are controlled experiments. Replit, Invariant Labs, and OpenAI are, respectively, an operational incident, an exploit demonstration, and an incident in an evaluation environment.

1. Microsoft (2026). Cyber Pulse — AI Agent Governance.
2. Cloud Security Alliance (2026). The Identity and Access Gaps in the Age of Autonomous AI.
3. Cloud Security Alliance (2026). Autonomous but Not Controlled.
4. IBM (2026). Cost of a Data Breach Report.
5. IBM Brazil (2026). Average cost of a data breach in Brazil.
6. OWASP (2025). Excessive Agency — LLM06:2025.
7. OWASP (2025/2026). Top 10 for Agentic Applications.
8. OWASP (2026). Agent Control Standard.
9. NIST (2020). SP 800-207 — Zero Trust Architecture.
10. Alizadeh et al. (2025). Simple Prompt Injection Attacks Can Leak Personal Data Observed by LLM Agents During Task Execution.
11. Debenedetti et al. (2024). AgentDojo — NeurIPS.
12. Invariant Labs (2025). GitHub MCP Exploited.
13. Fast Company (2025). Replit AI Agent Database Incident.
14. OpenAI (2026). The Hugging Face Incident and the Road Ahead.
15. PostgreSQL Global Development Group. Database Roles.

Technical analysis and product essay. It does not report experimental efficacy results for GatekeeperID Agents and it is not a certification of compliance with the standards it cites.