Agentic AI can automate useful work, but it also changes the security model. A chatbot that only answers questions is one risk profile. An AI agent that can call APIs, read customer data, update tickets, trigger workflows, or act across tools is another.
That is why SaaS teams should review open-source agents and agent frameworks with the same seriousness they bring to any privileged service. The question is not only “what does the model say?” It is “what can the agent do?”
What agentic AI security risks look like
The OWASP Top 10 for Agentic Applications highlights how autonomous, tool-using systems introduce risks beyond classic chatbot prompts. For SaaS teams, the most practical categories include:
- Tool misuse: The agent uses an allowed tool in an unsafe way, such as sending data to the wrong place or taking an action out of sequence.
- Identity and privilege abuse: The agent runs with broader permissions than its task requires, creating a larger blast radius.
- Prompt injection: User-controlled content or external data manipulates the agent into ignoring instructions or leaking information.
- Memory and data exposure: Sensitive information is stored, reused, or surfaced in the wrong context.
- Supply chain risk: Agent skills, plugins, dependencies, or connectors introduce vulnerabilities or unexpected behavior.
- Weak accountability: Teams cannot reconstruct what the agent did, which data it accessed, or why it took a specific action.
Why open-source agents need extra review
Open-source agents can be valuable because they are flexible, inspectable, and fast to prototype with. They also tend to be deployed quickly by teams eager to automate internal work. That speed is where risk enters.
Before adopting an OpenClaw-style or other open-source agent, review how it handles secrets, local files, network calls, browser automation, plugins, logs, updates, and default access. If the agent can reach production systems, it should go through production-grade review.
Traditional SaaS security versus agentic AI security
| Traditional SaaS control | Agentic AI security need |
|---|---|
| User roles and login review | Agent identities, scoped tokens, and delegated permission review |
| UI-based access boundaries | API, tool, connector, and cross-service data boundaries |
| Periodic audits | Continuous monitoring of tool calls, data access, and unusual behavior |
| Manual approvals for sensitive work | Human-in-the-loop checkpoints for high-impact agent actions |
A practical review checklist
- Inventory agents: Know which agents exist, who owns them, and which systems they can access.
- Limit permissions: Use least-privilege scopes and separate tokens by workflow.
- Review tools and connectors: Audit every integration, plugin, or skill the agent can call.
- Protect secrets: Keep API keys out of logs, prompts, memory, and local files where possible.
- Isolate risky workflows: Run experiments away from production data until controls are proven.
- Add approval steps: Require a human for refunds, account deletion, permission changes, data exports, and other sensitive actions.
- Log decisions: Store enough context to review what the agent did and why.
- Test prompt injection: Include hostile support messages, web pages, emails, and documents in security testing.
What this means for support and feedback teams
Support workflows often sit close to sensitive customer data: account details, bug reports, screenshots, logs, billing questions, and private conversations. An AI support agent needs enough context to help, but not unlimited access to everything.
Use an AI support agent such as Kai Support with clear knowledge boundaries, multichannel support context, and human escalation. When collecting diagnostics through in-app bug reports, review what data is captured, who can access it, and how long it is retained.
Support chatbot and copilot risks
Support adds two surfaces to the agentic threat model. A customer-facing agent reads messages from anyone who opens the chat. An agent-facing copilot reads internal notes, past tickets, and connected tools on behalf of a teammate. They fail in different ways.
| Surface | Main risks | Controls |
|---|---|---|
| Customer-facing agent | Prompt injection in customer messages, internal notes or another customer’s data in a public answer, account-specific answers before the customer is verified | Public knowledge only, identity checks before account answers, sensitive topics routed to a person |
| Agent-facing copilot | Oversharing: the copilot can read more than the teammate needs, and injected text in an email or ticket can steer what it reads and returns | Least-privilege access, separate sources for public, internal, and incident content, drafts that a teammate reviews |
| Agent with tools | Unsafe actions such as settings changes, data exports, or billing changes without an approval path | Allowlisted actions, human approval for high-impact actions, a log of every call |
Copilot risk is not theoretical. EchoLeak (CVE-2025-32711), reported by Aim Security and fixed by Microsoft in June 2025, showed that a single crafted email could make Microsoft 365 Copilot leak internal data without any click from the user. There is no evidence it was exploited (The Hacker News, June 12, 2025).
Start with the knowledge layer. Keep public help articles, internal troubleshooting notes, policy documents, and incident material in separate sources. Customer-facing answers come from public content. When a question needs internal context, let a copilot draft the reply for a teammate instead of answering the customer directly. In Gleap, you tag content to scope what Kai Support may use, and the default scope excludes content tagged internal.
Which support actions an agent may take
OWASP calls the underlying risk excessive agency: an agent with more functionality, permissions, or autonomy than its task needs can do damage when its output is wrong or manipulated. Its guidance includes minimal tools, minimal permissions, and human approval for high-impact actions (OWASP LLM06:2025). In support, that translates into three tiers.
| Tier | Examples | Rule |
|---|---|---|
| Read and suggest | Search help articles, suggest a ticket label, summarize a thread | Automate and log |
| Low-risk writes | Create a support ticket, attach diagnostics, update a ticket field | Automate with logging and a way to undo |
| Account and money | Refunds, permission changes, data exports, account deletion, security responses | A person approves every time |
For anything in between, use a simple test: the agent may change a customer’s account only when the action is low risk, the customer is authenticated, the action is logged and reversible, and your policy allows it. Review read access and write access separately; suggesting a label is not the same as changing a permission.
Handoffs are a security control too. When a conversation involves a privacy request, an account access problem, a suspicious message, or a reported vulnerability, the agent should collect the minimum useful context, avoid speculation, and route the case to the right team. For technical issues, in-app bug reports capture diagnostics without asking customers to paste sensitive details into a chat thread.
In Gleap, Kai Support can call APIs or connected apps only when your team adds them as tools, which needs Team or above. Custom agents are on Team, Pro and Enterprise too; a custom agent can message a customer only through its Reply to customer tool, and human steps such as Ask for a decision or Request human input are tools you attach to it. For owners, review loops, and controls by autonomy level, see how SaaS teams govern AI support agents.
The safest path is controlled automation
Agentic AI security is not a reason to avoid automation entirely. It is a reason to treat agents as privileged actors inside your SaaS environment. Give them narrow jobs, narrow permissions, strong logging, and human oversight for sensitive work. In Gleap, custom agents run only with the tools you give them, and the Trust Center documents how Gleap handles security and data.
The teams that succeed will be the ones that automate deliberately: useful enough to reduce support load, controlled enough to protect customer trust.
