AI engineering needs ISO 27001

AI is no longer just answering questions. It's reading code, querying databases, calling tools, and making decisions on its own. Think of it as a very fast intern who never sleeps, never asks questions, and has the keys to the building.

That changes the security conversation. The question is no longer "Is our AI model secure?" It's "What happens when AI becomes part of the system that creates, accesses, changes, and acts on our information?"

Good news: you don't need a new playbook. ISO 27001's old friend, the CIA triad, maps neatly onto the problem.

Confidentiality: What can the AI see?

An AI coding agent might have access to your repos, tickets, CI/CD pipelines, cloud resources, and internal docs. That's a lot of keys on one keyring.

The risk: Customer data slips into prompts, agents get broader access than they need, or secrets show up in logs.

The fix:

• Give agents their own identities instead of letting them borrow a human's all-access pass
• Apply least privilege (an agent that reads code doesn't need production access)
• Classify data, and know what third-party AI providers are actually seeing

The rule: An agent should know only what it needs to do its job. Same as your best employees, minus the gossip.

Integrity: Can we trust what the AI changes?

This is the interesting one. Traditional security stops unauthorized people from changing things. With agents, we also worry about authorized systems making unintended changes.

Legitimate access doesn't make every action legitimate. An agent might add a vulnerable dependency, act on poisoned documents in a knowledge base, or push a misunderstood config change toward production.

The fix:

• Separate duties: the AI proposes, a human (or another control) approves
• Keep AI changes inside normal change management
• Validate and test everything it produces
• Keep audit trails: what did it do, what did it use, who approved it?

The rule: Being inside an authorized workflow isn't a trust badge. Confidence is not correctness.

Availability: What if the AI goes down?

Once AI sits in the critical path, outages stop being an IT inconvenience and become a business problem. Providers go offline. Agents get stuck in loops and burn through your cloud budget at 3 a.m. Models change behavior after an update, with no memo.

The fix:

• Backup models or providers
• Human fallback processes
• Rate limits, timeouts, and circuit breakers
• Continuity plans that explicitly name AI dependencies

The test question: If our AI is down for 24 hours, can we still ship software and support customers?

A reality check

ISO 27001 won't tell your engineers how to defend against prompt injection or design guardrails. That's not its job. It's a management system for identifying and controlling risk, and AI-specific engineering practices sit underneath it: threat modeling, technical controls, testing, monitoring, and continuous improvement.

The bottom line for leaders

Plenty of organizations have AI governance: policies, principles, responsible AI statements. Useful, but governance only pays off when it reaches the engineers. They need concrete answers: What can this agent access? What can it change? What if its input is manipulated? Can we trace what happened? What's the fallback?

Security isn't a bolt-on. It's a blueprint. AI engineering needs security engineering, and the best place to start is still three letters from decades ago: C, I, A.