Granting permissions to an artificial intelligence agent is not a configuration task: it's a risky decision that should be made with the same rigor as deciding who has signatory authority on a bank account. Each additional permission expands the potential for harm, and this expansion isn't offset by the quality of the model, because the risk doesn't stem from the model being flawed: it stems from the fact that it can be manipulated or make mistakes within the scope you've granted it.
The formulation we use internally is simple: An agent cannot cause harm in a place where he is not authorized.. The entire security design of an agentic system is derived from that phrase.
OWASP, in its 2025 Top 10 Risks for Language Model Applications, ranks prompt injection first for the second consecutive year, and dedicates an entire category—LLM06, *Excessive Agency*—to this exact problem. It breaks it down into three forms:
All three are design decisions, not model flaws. And all three are almost always made during the integration phase, for technical reasons and without anyone in the business knowing.
The link between these two approaches is indirect prompt injection: external content—an email, a PDF from a vendor, a web page, a customer ticket—containing instructions directed to the model. The agent reads this as part of its context and acts accordingly. If its permissions are broad, text written by a third party can end up executing actions within your systems.
This is why the safety of an agent is not solved by choosing a better model. It is solved by limiting what the agent can do when someone manages to influence it.
Here's a structural change that many organizations haven't incorporated into their access management. For twenty years, identity control was designed for people: onboarding, offboarding, roles, periodic reviews. Agents introduce identities that aren't people; they're created in minutes, don't appear on the organizational chart, and are rarely reviewed.
IBM's 2025 Cost of a Data Breach report provides the data that concludes the argument: The 97% of organizations that suffered an AI-related incident lacked adequate access controls. It's not a problem of the attacker's sophistication. It's a problem of permission hygiene.
We have covered it in depth in non-human identities, AI agents, and cybersecurity, But the operational summary is this: if your access management process does not include non-human identities, your access inventory is incomplete, and probably in the part that can do the most.
Not all permits have the same risk profile. This classification allows for a decision to be made in a thirty-minute meeting.
Level | What can the agent do? | Required control |
1. Limited reading | Query data for a specific domain | Access logging and volume limit |
2. Extensive reading | Consult multiple systems and sensitive data | Role-based permissions, data masking, auditing |
3. Reversible writing | Create drafts, proposals, pending records | Human validation before confirming |
4. Irreversible writing | Payments, customer communications, production changes | Explicit approval, double control, and reversal plan |
The rule of thumb is that Most of the business value is in levels 1 and 3, and most of the risk is in step 4. An agent who prepares the reimbursement and leaves it pending approval captures almost all of the time savings with a fraction of the risk of one who executes the reimbursement.
When someone insists on level 4, the right question is how much additional value it provides compared to level 3. It's usually the time it takes a person to press a button. It rarely makes up for it.
Identity of oneself by agent. Never a shared account or the reuse of an existing service account. Without a unique identity, there is no way to attribute what happened.
Minimum allowance per task, not per agent. If the agent performs three different tasks, each should have its own scope. A permission granted for one task becomes available for all the others.
Short-term credentials. Tokens that expire, not permanent keys in a configuration file.
Whitelist of stocks. Explicitly define which operations can be executed, rather than defining which ones cannot. The latter is always incomplete.
Volume and amount limits. An agent who can issue refunds should have a limit per transaction and per day. It's the same principle that applies to any individual with spending power.
Complete and immutable record. What was entered, what was decided, what was executed, with which version of the model, and who validated it. Without this, there is no audit or possible defense.
Stop switch. A mechanism to stop the agent without deploying code and without depending on the vendor.
None of the seven are unusual. They are all standard security practices applied to a new actor. What is striking is how often they are omitted precisely because the actor is new and doesn't fit into existing procedures.
The risk of this article is that it might be read as an argument for inaction. It is not. The approach that works is progressive scaling:
This is the same principle of tiered oversight that we apply when integrating AI components into enterprise systems, and the reason why governance is not a final phase of the project but a property of its architecture, as we explained in AI risks, hallucinations, and governance
Before approving any agent deployment, it's advisable to answer this: If a stranger could write the text that this agent is about to read, what is the worst thing they could get him to do?
If the answer is "consult public information," the risk is acceptable. If the answer is "issue a payment" or "write to all our customers," the design is not complete.
Because they determine the potential damage surface. An agent cannot cause damage where it is not authorized, regardless of the model's quality or whether it has been manipulated. OWASP dedicates a separate category to this problem in its Top 10 LLM Applications for 2025: Excessive Agency.
It is the granting of excessive capacity to an agent, in three forms: excessive functionality (access to tools that its task does not require), excessive permissions (identity with more privileges than necessary) and excessive autonomy (execution of high-impact actions without human validation).
It is the granting of excessive capacity to an agent, in three forms: excessive functionality (access to tools that its task does not require), excessive permissions (identity with more privileges than necessary) and excessive autonomy (execution of high-impact actions without human validation).
Seven: unique and non-shared identity, minimum permission per task, short-lived credentials, whitelist of allowed actions, volume and amount limits, complete and immutable logging of each execution, and a stop mechanism that does not require deploying code.
Only for reversible and low-impact actions, and only after measuring over a sufficient period what percentage of proposals are approved without changes. Removing human validation due to schedule pressure is the most common cause of incidents in agentic systems.
Similar to human access controls, but with more discipline: documented registration, assigned owner, reviewable permissions, credential expiration, and periodic review. IBM documented in 2025 that the 97% protocol for organizations experiencing AI-related incidents lacked adequate access controls.
Do you know exactly what each agent you have deployed can do? We audit the scope, identities, permissions, and traceability of your AI systems, and deliver the diagnosis in writing. Request the audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
