AI Agent Security: A Checklist Before Connecting CRM, ERP, and Internal Data
An AI agent is not safe to connect to CRM, ERP, internal documents, or a payment API just because its prompt says “do not make mistakes.” Before launch, the team must define what the agent can see, what it can do, who approves high-impact actions, and how an incident can be investigated. The safest delivery path is to begin with one narrow workflow, minimum privileges, and complete auditability, then expand capabilities only after testing.
The short answer: when an AI agent can retrieve internal data, call tools, or change records, treat it as a technical identity with its own permissions, controlled tool access, and observability. Prompt instructions alone are not a security boundary.
Unlike a basic FAQ chatbot, an agent can reason through a task, choose a next step, use tools, and connect with existing systems. IBM describes agentic workflows as combining models, tools, feedback mechanisms, and integrations. Those integrations create business value, but they also expand the attack surface.
Why AI agents need their own security model
A public-information chatbot has limited blast radius. An agent that searches contracts, drafts commercial offers, updates a CRM record, or checks an order status touches data and business actions. A design failure may therefore cause more than an inaccurate answer: it may expose sensitive information, write the wrong data, or invoke an inappropriate API action.
Agentic systems also process natural language, and not every text source is trustworthy. A web page, email, or uploaded document can contain instructions designed to change the agent’s behavior. This is commonly known as prompt injection. IBM identifies prompt injection, excessive permissions, insecure tool access, and weak auditing as major agent-security risks.
The response is not to avoid agents. It is to apply the right sequence: define boundaries and visibility before increasing autonomy.
When an agent should not receive direct access
| Situation | Why it is risky | Safer first release |
|---|---|---|
| The agent handles personal, financial, or confidential business data | Retrieval or integration mistakes may disclose data to the wrong person | Read-only mode with source filtering and user-permission checks |
| The agent can initiate payments, change bank details, or delete records | The cost of an error can be high and irreversible | The agent prepares a draft; a person confirms the action |
| The workflow consumes emails, documents, or internet content | External content can contain malicious instructions or false information | Isolate the content and prohibit autonomous calls to sensitive tools |
| No process owner or escalation path exists | Nobody can decide how to handle exceptions or investigate incidents | Limit the agent to recommendations and assign a business owner |
| There are no action logs or replayable traces | The team cannot explain what happened or why | Do not launch until an audit trail and monitoring are available |
A single red flag does not mean the use case is impossible. It means the autonomy level should change from “act” to “collect evidence, recommend, and wait for approval.”
The 10-point AI agent security checklist
1. Define one specific business workflow
Do not start with “we need a corporate AI assistant.” Start with a bounded task. For example: the agent receives a customer request, searches an approved knowledge base, and prepares a reply draft. Define inputs, expected output, exceptions, and the accountable process owner.
Narrow first workflows are easier to evaluate for quality, permission scope, and business impact. Scale a proven workflow rather than an untested list of capabilities.
2. Classify data before connecting sources
Inventory every source: CRM, ERP, file storage, knowledge base, mail, and partner APIs. Label what each contains: public, internal, personal, financial, contractual, or technical-secret data. Then decide separately what the agent may retrieve, what it may show to a user, and what must never enter its context.
Access to a source does not automatically grant the right to disclose all retrieved records. The agent must enforce the requesting user’s permissions, not simply use the maximum permissions of an integration account.
3. Give the agent a dedicated identity
Do not use an administrator’s personal token or a general-purpose key shared by integrations. Give the agent a dedicated service identity, separate credentials, and an explicit lifecycle for rotation, revocation, and review. This makes its activity visible and makes it possible to disable the agent without disrupting unrelated systems.
For high-risk use cases, separate identities by workflow. A support agent should not inherit the permissions required by a finance workflow.
4. Enforce least privilege and RBAC
Least privilege means the agent receives only the rights needed for a defined task. An agent that reads an order status does not need permission to edit a customer profile or export the entire database. Role-based access control (RBAC) ties permissions to the user role and scenario, not merely to a tool.
IBM recommends pairing permission boundaries with guardrails, audit logging, and observability. The controls work together: permissions limit potential damage, while monitoring identifies unusual behavior.
5. Separate read, draft, and action modes
Use a maturity model. At level one, the agent reads authorised data and cites the source. At level two, it creates drafts: a report, email, CRM note, or request. At level three, it invokes an action API.
For many business workflows, human approval should remain between level two and level three. A user should see the proposed change, supporting information, and an explicit confirmation control before the agent changes a deal status, sends a consequential message, or starts a financial process.
6. Treat every tool as a risk boundary
An API, search connector, file store, document generator, or script runner is not just a feature. It has its own data, authority, and failure modes. Before enabling a tool, ask: what inputs does it accept; which operations can it trigger; what does it return; and what is the maximum impact of misuse?
Allow only tools that belong to the active workflow. For sensitive actions, add parameter allowlists, volume or amount limits, rate limits, and human approval.
7. Defend against prompt injection in incoming content
The agent must not treat everything it reads as a command. Content retrieved from web pages, emails, or documents is data, not a policy source. Keep system rules and security policies separate from retrieved text; label content origin; sanitize untrusted material; and never let retrieved content modify the agent’s available tools.
Use adversarial test cases before launch: documents that contain conflicting instructions, attempts to expose confidential data, and text that tries to make the agent call a sensitive API. Red-team testing becomes more important as access broadens.
8. Set output and data-disclosure rules
Secure the output as carefully as the input. For each data class, define whether the agent may show it, whether fields must be masked, and whether export or onward transmission requires approval. Consider separately whether an answer may be copied into email, a CRM comment, a partner system, or a public channel.
For internal answers, show the source and confidence where possible. When evidence is insufficient, “requires a human review” is safer than an invented completion.
9. Create an audit trail and observability before launch
A minimum audit record should capture: who started the workflow, the user request, sources queried, tools invoked, relevant parameters, results, and the person who approved any action. Logs require their own data-protection policy; do not indiscriminately store secrets or personal data.
Track operational signals as well: source-backed answer rate, escalation rate, tool failures, latency, denied actions, and unusual data-access patterns. Observability turns a launched system into an operable one.
10. Prepare a kill switch and incident path
The team needs a clear answer to “what happens when the agent behaves incorrectly?” At minimum, provide an emergency disable control, credential revocation, per-tool shutdown, preserved logs, owner notification, and rollback for reversible actions. For material integrations, define decision owners and response timelines in advance.
Example: an agent that triages B2B requests
Consider a B2B portal that receives client enquiries. The unsafe design lets an agent read every email, search every folder, change the deal stage, and send a reply. A controlled first release looks different.
| Step | Agent activity | Security control |
|---|---|---|
| 1 | Extracts the topic and entities from a new enquiry | Does not execute instructions from the email or open unsafe attachments |
| 2 | Searches only the approved knowledge base | Uses read-only access and applies the employee’s permissions |
| 3 | Creates a reply draft and CRM-note draft | Cannot send email or change the deal stage automatically |
| 4 | Sends the draft to the account manager | Shows the supporting sources for review |
| 5 | Updates CRM after approval | Uses a separate permission, audit log, and reversal path |
This design reduces manual work without transferring an irreversible decision to the agent. Once quality and operational metrics are proven, autonomy can grow for narrow, well-controlled actions.
How to start
Begin with a discovery session involving business and technical owners. Define the process, success metric, participating data, permitted actions, human-approval boundaries, and required integrations. Build an MVP with constrained access, adversarial tests, and audit logs. Expand systems and privileges only after the first workflow works safely in production.
Piplos Media develops AI solutions for business, including AI agents, assistants, integrations, SaaS products, and intelligent automation. The team can help turn a business workflow into a secure first release, from discovery and architecture through interface, backend, infrastructure, testing, and support. See examples of delivered digital products in the Piplos Media portfolio.
FAQ
Can an AI agent access our CRM?
Yes, provided that access is limited to the required objects and actions. A first release often uses read-only access or creates a draft for an employee to approve before a critical field is changed.
Is a strong prompt enough to prevent risky actions?
No. A prompt is one behavioral layer, not a technical control. Use RBAC, dedicated credentials, tool allowlists, approval gates, limits, and audit logs as enforceable controls.
Does security slow down AI-agent delivery?
Not when the first workflow is narrow. A clearly bounded MVP with safe integrations is typically faster to deliver than a universal autonomous assistant connected to every business system.
Must a person approve every agent action?
No. Human approval belongs where errors have material consequences: money, personal data, deletion, customer status, or legally significant communication. Low-risk, reversible actions can be automated after testing and monitoring are in place.
