Information security in AI projects

When a company connects AI to its ERP, CRM and email, it builds something very useful and, at the same time, a new way in. Many AI projects start as experiments, skip security review, and reach production with far too much access. Securing AI does not require a full security department. It requires understanding where the new risks sit and applying basic controls with discipline.

The risks AI adds

Classic risks such as weak passwords, unpatched systems and excess access still apply. AI adds a few of its own:

• Prompt injection: malicious text hidden in an email, PDF or web page tells the assistant to ignore its rules or leak information. The more outside content an agent reads, the greater the exposure.
• Data leakage: confidential information sent to tools without proper contracts, or shown to people who should not see it because permissions were loose.
• Over-empowered agents: an agent that can send emails, change orders or issue refunds will take real actions if it is tricked.
• Supply chain: models, libraries, plugins and third-party connectors are code you did not write.
• Exposed secrets: API keys in code, spreadsheets or prompts are an old problem, now at scale.
• Insecure outputs: AI-generated text or code that is executed or inserted into a system without validation can cause failures or vulnerabilities.

Core principle: treat AI like a very fast intern

It is capable and eager, but it can be fooled and does not know your business boundaries. You would not give an intern full access to finance on day one. Apply the same logic: least privilege, supervision and an audit trail.

Essential controls

Access and identity

• Give the AI only the permissions the task needs, preferring read-only access.
• Have the assistant inherit the calling user’s permissions instead of using one powerful shared credential.
• Enforce multi-factor authentication and separate accounts per environment.

Data

• Classify data as public, internal or restricted, and define which tools may receive each class.
• Mask or anonymize personal data when the task allows.
• Choose business plans whose contracts bar training on your data and define retention. If you handle regulated data, confirm the vendor can support the relevant requirements, such as SOC 2 reports or a HIPAA business associate agreement.

Agents and automations

• Require human approval for irreversible or high-impact actions: payments, deletions, bulk sends.
• Cap amounts, volumes and recipients by rule, not by trusting the model.
• Treat all external content an agent reads as untrusted and keep it separate from system instructions.

Infrastructure and secrets

• Store keys in a secrets manager, never in code or documents, and rotate them regularly.
• Keep dependencies patched and review connectors and plugins before installing them.
• Encrypt data in transit and at rest.

Monitoring

• Log who asked what, which data was accessed and which actions the agent took.
• Alert on abnormal volumes, denied-access attempts and suspicious patterns.
• Set a retention period for logs, since they contain sensitive data too.

Test before you trust

Before going live, simulate simple attacks: tell the assistant to ignore its instructions, try to extract another user’s data, plant malicious text in a document it will read. Repeat after every model or tool change, because behavior can shift. Hypothetical example: a support agent that looks up orders starts revealing another customer’s details when the user supplies someone else’s order number. A 20-minute test would have caught it before a customer did.

A one-page checklist

1. An inventory of AI tools and the data each one touches.
2. Least privilege and inherited permissions.
3. Contracts with privacy and retention commitments.
4. Human approval on critical actions.
5. Secrets in a vault, with rotation.
6. Logs, alerts and a named person who investigates.
7. Abuse testing before launch and after each significant change.
8. An incident response plan that accounts for state breach notification laws and customer contract obligations.

Perfect security does not exist, but the gap between an exposed project and a defensible one usually comes down to simple decisions made early. Building these controls in costs far less than retrofitting them after an incident. Frameworks like the NIST AI Risk Management Framework and the NIST Cybersecurity Framework offer useful structure if you want a recognized reference to align with.

It also helps to name who owns security for each project, even if one person wears that hat part-time. When nobody owns the topic, controls turn into good intentions that never leave the page, and periodic review never happens. If you work with an outside partner, put security responsibilities, incident notification timelines and data return or deletion at the end of the engagement into the contract, along with clear NDA and IP terms.

Want to put this to work? Convertty’s senior team runs an AI assessment of your workflows and delivers an implementation plan with 30-day quick wins. Book a call.