AI security inside your existing security programme

Models can amplify breaches — a single over-scoped API key may expose customer records via retrieval. Paste into consumer chat tools bypasses DLP investments.

Regulators ask how AI systems are secured and monitored. Audit findings on logging gaps block production scale.

Attackers target AI supply chains — poisoned dependencies, compromised model weights, malicious browser extensions marketed as productivity aids.

Security mistakes erode adoption. One public leakage incident triggers bans that slow legitimate programmes for years.

Incident response playbooks must cover model-specific scenarios: prompt injection causing unintended transfers, RAG retrieving documents the requester should not see, API key leakage in repos.

Treat security reviews as recurring production gates — not a one-time pen-test memo — because model vendors, plugins, and employee tooling change faster than annual audit cycles.

Core controls: (1) Identity — SSO, RBAC, service accounts with least privilege. (2) Data classification enforcement at input — block prohibited classes, redact where needed. (3) Network — private endpoints, egress controls for model APIs. (4) Secrets management — no keys in prompts or repos. (5) Application security — injection testing for agent tools, output encoding. (6) Logging and SIEM integration — queryable audit trails per policy. (7) Vendor security review — subprocessors, retention, penetration test results. (8) Incident response playbooks for model abuse.

Align with /resources/guides/shadow-ai-enterprise and /resources/guides/ai-policy-template-enterprise for acceptable-use enforcement.

Products like /products/approvals add approval-layer security for high-impact actions agents might trigger.

Segment environments — dev, staging, production — with separate keys and data. Prompt injection tests belong in CI for agent features before production promotion.

Map each control to a named owner in your GRC tool — empty RACI rows are how audits find gaps months after go-live. Revisit the map when vendors add plugins or employees adopt new browser extensions.

Treating AI as experimental and skipping change control — then promoting the same code to production unhardened.

Logging prompts/responses without retention policy — creating new compliance problems.

Granting agents broad write access to ERP "to be useful" — recipe for fraud or mass bad postings.

Security review after purchase — architecture blocks deployment late and expensively.

Logging full prompts indefinitely without retention policy — creating a larger sensitive datastore than the original systems.

Teams often repeat these mistakes after reorgs or vendor changes — keep a short incident log so new managers inherit lessons instead of rediscovering the same failure modes.

Skipping red-team exercises on RAG because "we only index internal docs" — retrieved content can carry indirect injection payloads attackers plant in shared drives.

Treating browser extensions as out of scope — many paste paths run through unofficial plugins with broad page access.

We threat-model each use case during design — data flows, tool permissions, human override points. Security requirements are in pilot charters, not post-go-live tickets.

We integrate with your existing controls — AD groups, DLP, SIEM — rather than bespoke AI-only stacks. Vendor selections include security scorecards from /ai-consulting/vendor-tool-selection.

When security gaps block production, we report clearly and sequence fixes — we do not bypass controls to meet demo dates.

Threat models accompany each agent integration — allowed tools, max blast radius, circuit breakers — reviewed with your SOC and appsec, not only AI delivery teams.

Engagements exit with a handover checklist tied to this guide — owners, dashboards, and policy links — so your team can operate without consultant dependency after hypercare ends.

Red-team exercises for agents should include indirect prompt injection via retrieved documents, not only direct user prompts — RAG expands attack surface.

Week 0–2 — inventory: CISO or delegated security lead lists every AI touchpoint — sanctioned apps, API integrations, shadow tools from readiness interviews. AppSec owner maps data classes flowing into each path and assigns risk tier. Gaps feed policy and procurement priorities, not slide decks alone.

Week 2–4 — identity and secrets: IAM team enforces SSO and RBAC on production AI surfaces; platform engineering moves model API keys into vault with scoped permissions and rotation schedule. SOC defines log fields, retention limits, and SIEM correlation rules; legal approves retention against privacy policy.

Week 4–6 — testing and vendors: AppSec runs prompt-injection and tool-permission tests on agent features in staging before promotion. Vendor management completes security questionnaires for foundation-model providers; gaps become procurement red-lines, not post-signature surprises.

Week 6–8 — response readiness: model or product owner drafts incident playbooks for leakage, injection, and RAG over-retrieval with named on-call roles. DLP rules for paste-to-consumer tools activate with manager escalation paths documented in policy.

Production gate: security liaison signs tier-specific control checklist; exceptions require risk committee note with expiry date. Review quarterly alongside shadow-AI reports — rising unsanctioned use triggers re-assessment, not only annual audit cycles. AppSec re-tests agent tools after major model or plugin upgrades.

Phase 1 (weeks 1–2) — sponsor and process owner agree scope, baseline metrics, and prohibited automations; security confirms data classes and logging defaults; legal confirms jurisdiction and retention. Phase 2 (weeks 3–8) — pilot on one queue or entity with hypercare office hours; champions named per site; override sampling weekly. Phase 3 (month 3+) — steering reviews expand/stop/fix with evidence; only then fund multi-entity rollout. Skipping Phase 1 produces demos that fail audit; skipping Phase 2 produces shelfware after launch email.