AI Agent Security: Why Permissions Alone Are Not Enough
An expert interview with Michael Kantor, founder and president of HOL, on testing AI agent permissions, preventing unauthorized actions, and verifying whether security controls actually work.
AI agents are moving beyond answering questions. They can send emails, update customer records, execute commands, access company data, and interact with external services.
That creates a new security challenge. Giving an AI agent a separate identity and restricting its access is important, but it does not necessarily prevent the agent from taking an inappropriate action with permissions it legitimately holds.
So how can businesses distinguish between actions an AI agent should perform automatically, actions requiring human approval, and actions that should never be permitted?
To explore these questions, TechNovice spoke with Michael Kantor, founder and president of HOL, an open-source organization working on infrastructure and security controls for AI agents.
In this written interview, Kantor explains how businesses can test AI agent permissions, why security logs are not sufficient evidence of protection, and what his team learned from real security testing.
1. Why isn't giving an AI agent its own identity enough to make it secure?
TechNovice: Giving an AI agent its own identity is an important first step. What security challenges remain when the agent starts taking actions?
Michael Kantor: Identity tells you who is acting. It doesn't tell you whether a particular action should happen.
An agent with its own account and a scoped token can still send the wrong email, delete the wrong record, or paste a customer list into a shared channel. The identity system will see each of those calls as authorized.
The open question is whether a specific action should be allowed, reviewed by a person, or stopped.
That decision depends on the agent, the tool it uses, the arguments it provides, and the data involved.
Afterward, you also need a record connecting the security decision to what actually happened.
An access policy can answer whether an account is allowed to write to a CRM. It usually cannot determine whether the agent should update 4,000 contacts at that particular moment.
Most of the potential damage I worry about sits in that second question.
2. Which AI agent actions should be allowed, require approval, or be blocked?
TechNovice: Let's take a common business scenario: an AI agent that works with emails and a CRM. How would you decide what it can do independently?
Michael Kantor: I would divide actions into three categories.
Allow automatically:
Reading emails and searching CRM records.
Summarizing conversations.
Creating email drafts without sending them.
Adding notes to individual contacts.
Require human approval:
Sending emails to external recipients.
Changing deal stages or financial amounts.
Merging customer contacts.
Exporting more than a handful of records.
Performing actions involving billing.
Block entirely:
Bulk deletion of records.
Changes to user permissions or API keys.
Forwarding emails to external domains.
Sending customer data to unapproved tools or URLs.
The distinction comes down to reversibility and who is affected.
An incorrect draft that nobody else sees is relatively inexpensive to fix. A sent email or deleted customer record may be impossible to undo completely.
I would start with strict rules and gradually relax them after observing how the agent behaves during normal work.
3. How can companies safely test AI agent permissions?
TechNovice: How can a team verify that an AI agent correctly follows these rules before connecting it to real customer information?
Michael Kantor: Start with an isolated test environment.
Create a test CRM with fictional contacts, a test mailbox, and credentials that only provide access to those systems.
Before executing anything, document each test case:
What is the agent being asked to do?
Should the action be allowed, require approval, or be blocked?
What should the agent do next?
Which changes are permitted?
Then test the expected outcomes.
For example, asking an agent to summarize the last five emails from a fictional customer should be allowed without changing anything.
Asking it to email a quotation should trigger an approval request. Before granting approval, check that the email has not already been sent.
After approval, verify that exactly one message reached the intended recipient.
Finally, ask the agent to delete every contact with a particular tag. The request should be blocked. Count the relevant CRM records before and after the test to confirm that nothing was removed.
For every test, I recommend collecting three types of evidence:
The security tool's decision.
The AI agent host's activity log.
The actual state of the mailbox, CRM, or other affected system.
Keep expected and observed results separate. Otherwise, it becomes easy to mistake what should have happened for what actually happened.
4. If a security tool says an action was blocked, how can you know it really was?
TechNovice: Many security products provide dashboards showing blocked actions. Why isn't that sufficient proof?
Michael Kantor: A security log tells you what the tool decided. It doesn't necessarily tell you what the underlying system did.
You need to examine the system where the action would have taken effect.
For emails, check the Sent folder and the provider's message logs.
For CRM operations, inspect the record's change history.
For software development tasks, compare repository files or Git status against a snapshot taken before the test.
You should also check whether the agent achieved the same result through a different route.
An agent might attempt an action using another tool, a script, or a scheduled task after its first attempt was rejected.
If the agent's transcript says it couldn't perform an operation, but the CRM history shows that a record was modified at the same time, trust the CRM evidence.
There is also an important distinction between preventing an action before execution and merely recording it afterward.
Both events can look similar on a security dashboard. Only the first actually prevents the action.
5. Can AI agent security controls be bypassed?
TechNovice: Where can security controls fail? And what happens when the security layer itself becomes unavailable?
Michael Kantor: A security control only protects the paths into which it has been integrated.
With HOL Guard, for example, enforcement depends on the AI agent host and the type of event. We publish a coverage matrix explaining which actions can be blocked, reviewed, observed, or are not covered.
Common gaps include tools the security layer cannot see, such as newly added MCP servers.
Indirect actions are another problem. An agent might create a script that runs later through a scheduled job or modify a configuration file that another program subsequently reads.
Overly broad approvals can also introduce risks.
Prompt injection adds another challenge. A security layer may prevent a covered action triggered by malicious instructions. However, it cannot necessarily prevent the model from being misled in the first place.
And it cannot stop actions executed through paths it does not monitor.
When a security component becomes unavailable, the outcome depends on how the agent host handles an unanswered security check.
For HOL Guard, local security decisions do not depend on its cloud service. Therefore, a cloud outage does not automatically disable those decisions.
But local failures still need testing.
I would not accept a vendor's claim that its product fails closed until I had verified that behavior in my own environment.
6. How do you prevent employees from blindly approving AI agent requests?
TechNovice: Human approval sounds sensible, but too many approval requests can become counterproductive. How should companies handle this?
Michael Kantor: Ask for approval only when an incorrect decision would be expensive and the action is uncertain.
If every file read generates a prompt, people will quickly develop the habit of clicking yes without reading.
Three approaches help.
First, allow routine reads and reversible actions without unnecessary interruptions.
Second, make approvals specific to the action being requested. Approving a particular command with specific arguments is safer than permanently allowing an entire tool.
Third, address false positives quickly.
We recently encountered an example in HOL Guard where commands using an output option such as --format json were flagged for review because the system interpreted the word "format" as a possible disk-formatting risk.
We corrected that behavior.
An effective approval request should explain:
What exactly will happen.
Which recipient, record, or file is affected.
Why the action requires approval.
Whether the action can be reversed.
Whether approval applies once or to future similar requests.
A generic message saying that an agent wants to execute a shell command does not provide enough information for an informed decision.
7. What has your own security testing revealed?
TechNovice: Can you share a documented example where the intended security policy did not match what actually happened?
Michael Kantor: One example from our work on HOL Guard involved reusable approvals for Git commands on Windows.
This was an observation from our own testing, not a customer security incident.
Guard allowed users to approve an exact action so that repeating the same command would not require another approval.
On Windows, we connected the saved approval to a fingerprint representing the Git command and its inputs.
The intention was that the approval would apply only to that specific action.
However, Git can also interact with repository configuration, attributes, hooks, and helper programs.
Across four review rounds, we continued finding ways for those mechanisms to execute code that was not represented by the original fingerprint.
Tests on the earlier implementation confirmed that even a command such as git status could retain reusable approval despite those additional execution paths.
Rather than attempting to patch every possible configuration scenario individually, we changed the approach.
HOL Guard no longer saves reusable approvals for Git commands on Windows. Each invocation requires one-time approval instead.
The investigation and test results are documented in GitHub pull request #4959.
A second example involved approval behavior.
In a live test, a user could approve an action for one-time execution, but the agent's subsequent retry was still denied.
The dashboard nevertheless instructed the user to return to the agent and retry.
We corrected the information presented by the approval interface so it would no longer promise behavior that the underlying integration could not deliver.
That change is documented in GitHub pull request #3856.
Both cases illustrate why security controls need to be tested against their actual behavior, not just their intended design.
8. What are the first three security checks every small business should perform?
TechNovice: Many smaller companies are beginning to experiment with AI agents. What should they prioritize, and when are built-in protections sufficient?
Michael Kantor: I would recommend three initial checks.
First, inventory everything an agent can access.
List its accounts, API tokens, MCP servers, plugins, and connected tools.
Identify what each credential allows the agent to do and remove access it does not need.
Second, keep built-in approval mechanisms enabled.
Require confirmation for sensitive operations such as sending information, deleting data, or installing software.
Avoid configurations that automatically approve everything, particularly on machines containing real credentials.
Third, run a simple blocked-action test.
Attempt a harmless operation that should be rejected and independently verify that it did not take place.
Built-in permissions and sandboxing are often sufficient when an agent operates inside an isolated environment without production credentials, uses a limited set of tools, and requires human review before its output reaches other systems.
A coding agent working inside a container and submitting changes through a pull request is one example.
Additional security controls become more relevant when agents operate on machines containing real credentials, several agent tools need consistent policies, or organizations require detailed records explaining individual security decisions.
HOL Guard is one possible option. Its local version is free and open source under the Apache 2.0 license, while its optional cloud service provides shared policies and management capabilities.
However, the underlying principle applies regardless of the product being used: test what your agent can actually do.
The Takeaway: AI Agent Security Requires Evidence, Not Just Permissions
The central lesson from this interview is that securing an AI agent requires more than limiting its access.
A properly authenticated agent can still perform an inappropriate action. An approval interface can communicate something that the underlying system cannot enforce. And a security dashboard can report a blocked operation without proving that the intended outcome was prevented.
For businesses adopting autonomous workflows, the key questions are therefore practical:
Which actions can the agent perform without supervision?
Which operations require explicit human approval?
Which actions must never be allowed?
How can the organization independently verify that these rules are enforced?
The safest starting point is a controlled environment, limited permissions, carefully defined approval rules, and repeatable tests.
Organizations do not necessarily need another security product to begin. They do need to understand the actual boundaries of the tools they already use.
As AI agents become more capable, the ability to verify their actions will become just as important as the ability to authorize them.
About the Expert
Michael Kantor is the founder and president of HOL, an open-source standards organization working on infrastructure for AI agents. His work focuses on agent identity, communication, and security, including the development of HOL Guard.
Before founding HOL, Kantor worked in distributed and decentralized technology.
Sources and Further Reading
Editorial note: This interview was conducted in writing in October 2026. Responses have been edited for clarity and readability. The examples involving HOL Guard describe internal testing reported by its developers, not independently reproduced tests by TechNovice.
