Trustlook's Integration with OKC (OKX Chain)
San Jose, California, Oct. 19, 2022, Trustlook, the global leader ...
AI agents are moving beyond answering questions.
In customer support, sales, ecommerce, and internal operations, companies are increasingly giving AI systems access to tools that can change real-world systems: issuing refunds, updating orders, modifying accounts, creating tickets, sending messages, and triggering workflows.
That creates a fundamentally different security problem from a traditional chatbot.
If a chatbot gives a wrong answer, the damage may be limited to misinformation or a poor customer experience.
If an AI agent takes the wrong action, the impact can be financial, operational, or even security-related.
The question is no longer simply:
“Can the AI understand the customer?”
It is also:
“What should the AI be allowed to do?”
And perhaps more importantly:
“What happens when the AI is wrong?”
AI agents introduce a new permission layer
Traditional enterprise software usually gives permissions to people.
An employee may be allowed to:
- view customer information
- modify an order
- issue a refund
- change an account
- access billing information
- approve a discount
AI agents introduce another actor into that permission model.
But giving an AI access to a tool does not mean it should have unrestricted authority to use it.
For example, a customer may write:
“My order arrived damaged. Can you refund it?”
An AI agent may correctly determine that the customer is asking for a refund. But several other questions still need to be answered:
- Is the order actually eligible?
- Has it already been refunded?
- Is the customer requesting the correct amount?
- Does the request fall within company policy?
- Is there any fraud or abuse signal?
- How much authority does this AI agent have?
- Should a human approve the action?
These questions should not depend entirely on the language model.
Treat the model as a decision-maker, not the security boundary
One of the most important design principles for agentic systems is to separate AI reasoning from authorization.
A model can propose an action:
Refund order #1234 for $89.
But another layer should determine whether that action is actually permitted.
For example:
- The AI identifies the customer's intent.
- The system retrieves the relevant order.
- The AI proposes a refund.
- A policy layer checks eligibility and limits.
- The refund API verifies the current order state.
- The action executes only if every required condition is satisfied.
The AI can still make the decision about what it wants to do.
It simply does not get final authority over whether the action is allowed.
This is similar to the principle of least privilege in cybersecurity: every actor should receive only the permissions required to perform its job.
Start with explicit action limits
A simple way to introduce AI actions safely is to define clear authority boundaries.
Consider refunds.
A business might decide:
- refunds under $50 that clearly meet policy → automatic
- refunds from $50–$200 → automatic if additional conditions are met
- refunds above $200 → human approval required
- suspected fraud → always escalate
- request outside refund policy → agent cannot execute
The specific numbers will differ between businesses.
The security principle is what matters:
The model should not be able to increase its own authority.
Even if the AI believes with high confidence that a $500 refund is justified, that confidence should not allow it to bypass a $200 authorization limit.
Model confidence and financial authority are two different things.
Enforce permissions outside the prompt
A common mistake is putting security rules only inside the AI's instructions.
For example:
“Never issue a refund above $200.”
That is useful guidance, but it should not be the only protection.
Prompts can be misunderstood, overridden by conflicting context, or affected by unusual inputs.
Instead, the underlying refund function should enforce the rule itself.
If the AI requests:
refund(order=1234, amount=500)
the system should reject it regardless of what the model believes.
This gives businesses defense in depth.
The prompt says what the agent should do.
The authorization layer determines what the agent can do.
Don't give every agent every capability
As AI systems become more sophisticated, companies may use multiple specialized agents rather than one general-purpose agent.
A support agent may need access to:
- order lookup
- account information
- troubleshooting documentation
A billing agent may need:
- invoice information
- subscription changes
- refund capabilities
A sales agent may need:
- product information
- pricing
- checkout or quote generation
Those agents should not automatically share the same permissions.
An AI agent responsible for answering shipping questions probably does not need the ability to issue refunds.
A product-recommendation agent probably should not be able to modify billing details.
Specialization can therefore provide a security benefit as well as an operational one.
Human approval should be part of the architecture
Human escalation is sometimes described as a failure of AI automation.
From a security perspective, it is often the opposite.
A well-designed agent should recognize when a request exceeds its authority.
For example:
Customer requests a $1,200 refund.
The AI may be able to:
- identify the customer
- retrieve the order
- verify the relevant policy
- summarize the reason for the request
- determine that the amount exceeds its authority
- route the case to the appropriate human
- provide the human with all relevant context
The human only needs to make the higher-risk decision.
That is significantly more efficient than either extreme:
- making the human handle the entire workflow
- giving the AI unlimited authority
Preserve an audit trail
When an AI agent can take actions, organizations need to be able to reconstruct what happened afterward.
An audit trail should ideally answer questions such as:
- What did the customer request?
- What information did the AI see?
- What action did the AI propose?
- Which policy was applied?
- Was human approval required?
- What API or tool executed the action?
- What was the result?
- Was the action retried?
- Did the customer contact support again about the same issue?
This becomes particularly important for actions involving money, account access, personal information, or regulated workflows.
Conversation transcripts alone are not enough.
The transcript may show what the AI said, but not necessarily why a backend action was authorized.
Plan for partial failures
AI agents rarely operate in perfectly clean environments.
APIs time out.
Customer data becomes stale.
A refund may succeed even if the response to the AI times out.
A workflow may complete only partially.
This introduces another security and reliability requirement: idempotency.
Imagine an AI agent attempts a $100 refund.
The refund succeeds, but the API response is lost.
The agent retries.
Without the right controls, the customer could receive $200.
The system therefore needs a way to recognize:
“This refund request has already been executed.”
The ability to recover safely from uncertainty is just as important as the ability to perform the original action.
Real-world example: customer support agents
Customer support is one of the clearest places where these issues appear.
Platforms such as Aissist.io provide AI agents that work on top of existing customer support systems such as Zendesk, Intercom, Front, and Gorgias.
Instead of limiting the AI to answering questions, businesses can connect agents to systems such as ecommerce platforms or internal APIs so they can perform actions.
That makes the AI more useful—but it also makes permission design more important.
A company might allow its support agent to:
- look up an order automatically
- retrieve tracking information
- generate a checkout link
- process a low-risk refund
- escalate a higher-value refund
- route technical or billing cases to different teams
The goal is not to give the AI unlimited autonomy.
It is to give the agent enough authority to resolve routine cases while keeping higher-risk actions behind stronger controls.
A security checklist for agentic actions
Before allowing an AI agent to take actions, businesses should ask:
1. What systems can the agent access?
Document every tool, API, database, and workflow available to the agent.
2. What actions can it perform?
Separate read-only access from actions that modify state.
3. What are the authority limits?
Define financial, operational, and data-access boundaries explicitly.
4. Where are those limits enforced?
Critical controls should exist outside the model prompt.
5. Which actions require human approval?
Create clear escalation paths before the agent is deployed.
6. Are actions logged?
Record both proposed and executed actions.
7. Are retries safe?
Use idempotency and transaction controls where appropriate.
8. Can permissions be revoked quickly?
Organizations should be able to disable an individual capability without shutting down the entire AI system.
9. Can the agent explain why an action was denied?
Structured failure reasons can reduce the chance that the model invents an explanation.
10. What happens when systems disagree?
The underlying system of record—not the language model—should remain authoritative.
The safest AI agent is not the one that never acts
There is a temptation to solve AI-agent risk by keeping agents read-only.
That reduces risk, but it also removes much of the value of agentic AI.
The more useful goal is controlled autonomy.
An AI agent should be able to perform routine, well-defined actions independently while operating inside clear technical and business constraints.
The security question should therefore not be:
“Should we let AI take actions?”
It should be:
“Which actions should this AI be allowed to take, under what conditions, and what prevents it from exceeding those limits?”
As AI agents gain access to more business systems, those permission boundaries may become one of the most important parts of enterprise AI security.