Why AI Agents Need Limits, Not Superpowers
Key insights
- AI agents should be broken into small, collaborative units with minimal permissions rather than built as all-powerful super agents
- A 2x2 matrix of risk and capability determines how each agent should be managed, from static credentials to dynamic access control
- High-capability agents should be ephemeral (short-lived), while low-capability agents can safely persist
- High-risk, high-capability agents need human-in-the-loop approval before taking consequential actions
This article is a summary of 4 Ways AI Agents Should Behave for Smarter Systems. Watch the video →
Read this article in norsk
In Brief
Grant Miller, CTO of Access Transformation and Securing AI at IBM, presents a framework for designing AI agents that stay within safe boundaries. Instead of building a single all-powerful agent, Miller argues for breaking systems into small, specialized agents classified by risk and capability. The framework uses a 2x2 matrix to determine how each agent should behave: whether it should be short-lived or persistent, use static or dynamic access, and whether a human needs to approve its actions.
What is super agency?
The popular image of AI agents is a single, all-powerful system that can access anything and do everything. Miller calls this the "Hollywood view" of agents (0:34). It sounds impressive, but it creates two problems that make systems unsafe.
The first problem is super agency, where an agent has unlimited freedom to decide what it does (2:10). The second is over-privilege, where an agent has more permissions than it needs. It can read, write, delete, and update data even when its task only requires reading.
Explained simply: Think of a super agent like giving a new employee the master key to every room in the building, plus the authority to sign contracts, hire staff, and access the bank accounts on their first day. A well-run company gives access only to what each role needs. Unlike a real employee who can explain their reasoning if questioned, an AI agent may take actions that are difficult to trace or reverse.
The solution, Miller argues, is to minimize both actions and access (3:06). Each agent should have one specific task and only the permissions needed for that task. In software engineering, this is called high cohesion: a tight alignment between the agent, its task, and its access level.
The risk-capability matrix
Not all agents are equal. Miller introduces a 2x2 matrix that classifies agents along two axes (5:39):
- Risk: If something goes wrong, how much damage can happen? Low risk means limited damage. High risk means the agent touches sensitive systems like financial data or customer records.
- Capability: How much reasoning does the agent need? Low capability means it follows predetermined actions (fixed steps with no decision-making). High capability means it is non-deterministic, meaning it reasons about what to do and decides its own path.
Four quadrants with examples
Miller provides concrete examples for each quadrant (6:01):
| Low risk | High risk | |
|---|---|---|
| High capability | Internal style guide editor (rewrites text, no sensitive data) | Accounts payable system (figures out invoices, initiates payments) |
| Low capability | RAG wiki lookup (reads internal docs, returns answers) | Finance data extractor (read-only access to sensitive financial data) |
RAG stands for retrieval-augmented generation, a technique where the AI looks up relevant documents before answering a question.
Explained simply: Think of the matrix like hiring for different roles. A low-risk, low-capability agent is like a librarian who finds and returns books. A high-risk, high-capability agent is like a financial controller who reviews invoices, decides payment amounts, and transfers money. You would not give both roles the same level of authority. Unlike real employees, agents cannot be held legally responsible for mistakes, which makes limiting their authority even more important.
Four behaviors for safer agents
Once you know where an agent sits in the matrix, Miller outlines four behaviors that determine how it should operate.
Step 1 — Set the agent's lifespan
High-capability agents should be ephemeral (9:56). Ephemeral means short-lived: the agent starts, completes its task, and then disappears. Because these agents reason and take non-deterministic paths, keeping them alive creates unnecessary risk. Low-capability agents can be persistent. They handle a specific, repeatable task and stay running because their behavior is predictable.
Step 2 — Choose the access model
High-capability agents need dynamic access (10:29). Because they reason about which systems to interact with, you need to check their permissions at every step. Can they connect to this tool? Can they read or write? Each decision depends on what the agent is doing right now. Low-capability agents use static credentials, the traditional approach with API keys, certificates, and fixed permissions (11:10).
Step 3 — Add human approval for high-risk actions
When an agent sits in the high-risk, high-capability quadrant, add human-in-the-loop approval (11:51). Before the agent takes a consequential action, like initiating a payment, it pauses and asks a human: "This action is about to happen. Do you approve?" Only after approval does the agent proceed.
Step 4 — Apply business controls for high-risk, low-capability agents
For agents that handle sensitive data but follow predetermined steps (like the finance data extractor), apply standard business controls (12:17). These are the same controls organizations already use for traditional automated systems: audit logs, access reviews, and checks that the system follows company rules.
Checklist: Common pitfalls when designing agents
- Are you building a super agent? If one agent handles multiple unrelated tasks, break it into smaller agents with specific responsibilities. Each agent should have high cohesion between its task and its access.
- Does every agent have the same permissions? Review each agent against the risk-capability matrix. A wiki lookup agent should not have write access to production databases.
- Are high-capability agents running indefinitely? Make them ephemeral. Let them start, finish their task, and shut down. Persistent high-capability agents accumulate risk over time.
- Is there a human checkpoint for high-risk actions? Any agent that can modify financial data, delete records, or interact with external systems should require human approval before executing.
- Are you using dynamic access where it matters? High-capability agents that reason about their path need per-action access evaluation, not a static API key that grants blanket permissions.
Remember: The goal is not to make agents less useful. It is to match each agent's authority to its actual task, so the system stays safe as it scales.
Practical implications
For beginners exploring AI agents
Start with agents in the low-risk, low-capability quadrant. Build a simple RAG-based lookup agent that reads documents and returns answers. Give it read-only access to a single data source. This teaches the core principle of least privilege (giving only the minimum permissions needed) without introducing risk.
For developers building multi-agent systems
Map every agent to the risk-capability matrix before writing code. This shapes your key design choices: lifespan, access model, and whether you need human approval. Agents in the upper-right quadrant (high risk, high capability) require the most infrastructure, so plan for dynamic access evaluation and approval workflows early.
For organizations deploying agents at scale
Use the matrix as a decision-making guide. Create policies for each quadrant: what access controls are required, what audit trails must exist, and when human approval is mandatory. This gives teams clear guidelines without slowing down development for low-risk agents.
Test yourself
- Transfer: How would you apply the risk-capability matrix to a customer support system where agents handle both simple FAQ lookups and refund processing?
- Trade-off: Ephemeral agents are safer but cost more to spin up repeatedly. When would you choose a persistent high-capability agent despite the risk?
- Architecture: Design an agent system for a hospital that processes patient records (high risk) and schedules appointments (low risk). Which quadrants do the agents fall into, and what access model would each use?
Glossary
| Term | Definition |
|---|---|
| AI agent | A software program that can take actions on its own, like reading files, calling APIs, or making decisions, rather than just answering questions. |
| Dynamic access | Permissions that change based on what the agent is currently doing. Each action is evaluated individually, rather than granting blanket access upfront. |
| Ephemeral agent | An agent that starts, completes its task, and then shuts down. The opposite of a persistent agent that stays running continuously. |
| High cohesion | A design principle where an agent, its single task, and the access it needs are tightly aligned. The agent does one thing well and has exactly the permissions for that one thing. |
| Human-in-the-loop | A design pattern where a human must review and approve an agent's action before it executes. Used for high-risk decisions like payments or data deletion. |
| Least privilege | A security principle: give only the minimum permissions needed to complete a task. Nothing more. |
| Non-deterministic | Behavior where the agent reasons and decides its own path, rather than following fixed steps. The same input may produce different actions depending on context. |
| Over-privilege | When an agent has more permissions than its task requires. For example, an agent that only needs to read data but also has permission to delete it. |
| Persistent agent | An agent that stays running to handle repeated tasks. Suitable for low-capability agents with predictable behavior. |
| Predetermined actions | Fixed steps that an agent always follows in the same order. No reasoning or decision-making is involved. |
| RAG (Retrieval-Augmented Generation) | A technique where the AI looks up relevant documents before generating an answer, rather than relying solely on its training data. |
| Static credentials | Fixed access tokens like API keys or certificates that do not change based on context. Traditional approach for simple, predictable systems. |
| Super agency | When an agent has unlimited freedom to decide what it does, with no boundaries on its scope of action. |
Sources and resources
Want to go deeper? Watch the full video on YouTube →