ISACA<\/a> AAISM approach treats controls as part of enterprise risk treatment: selected from risk, implemented in architecture, monitored in operation, and tested independently enough to support assurance.<\/p>\nControl selection should start from a threat and risk model. Identity controls address unauthorized access, data controls address disclosure and poisoning, supply-chain controls address malicious dependencies, and agent controls address excessive or unintended action. One control should not be presented as solving every AI risk.<\/p>\n
Enterprise AI platforms should publish secure reference patterns. Approved RAG, model-serving, agent, fine-tuning, and evaluation patterns can include standard IAM, network, logging, encryption, and guardrail configurations that teams reuse instead of designing security from scratch.<\/p>\n
Identity boundaries should distinguish users, applications, training pipelines, model registries, agents, tools, and platform administrators. Each identity should receive only the operations it needs.<\/p>\n
Privileged AI administrators should use stronger authentication and separate identities from ordinary development. The ability to replace a model, change a guardrail, or alter retrieval permissions can change production behavior without touching application source code.<\/p>\n
Data access should follow classification. High-risk training data or knowledge bases may need dedicated accounts, projects, encryption keys, or vector namespaces to make tenant and domain isolation easier to prove.<\/p>\n
Prompt content should be treated as sensitive when it can contain customer data, secrets, incident records, legal text, or proprietary documents. Logging policy should minimize content retention while preserving enough evidence for operations.<\/p>\n
Data-loss-prevention controls can monitor prompts and outputs, but prevention begins with minimizing which confidential sources the application can retrieve or upload.<\/p>\n
Model artifacts should be stored in registries with versioning and restricted publish access. Promotion workflows can require signatures, hashes, evaluation status, and approved provenance before serving.<\/p>\n
Container and runtime images should be scanned and pinned. A trusted model can still be compromised by a vulnerable inference framework, malicious package, or privileged container configuration.<\/p>\n
Model endpoints should enforce authentication, quotas, input limits, and network policy. Public anonymous invocation should be an explicit product decision, not the accidental default.<\/p>\n
Prompt templates should separate stable system instructions from user-controlled values. Untrusted inputs should never be interpolated into system-level fields that grant them stronger instruction priority.<\/p>\n
Prompt firewalls and guardrails should be tested with multilingual, encoded, indirect, and multi-turn attacks. Attackers will not limit themselves to the obvious phrases used in demonstration examples.<\/p>\n
RAG controls should preserve source metadata such as owner, effective date, tenant, classification, and document status. Metadata allows retrieval filters to exclude unauthorized or superseded evidence.<\/p>\n
Vector-store access should be secured like the underlying data. Embeddings can reveal semantic information and should not be exposed merely because they are not human-readable documents.<\/p>\n
Agents should use allowlisted tools with narrow schemas. Avoid exposing \u201cexecute arbitrary SQL,\u201d \u201ccall any URL,\u201d or \u201crun shell command\u201d when the business need can be expressed through constrained operations.<\/p>\n
Tool backends should verify authorization independently. Model-generated claims about the user or intended action must not be trusted as proof of permission.<\/p>\n
Rate limits and execution budgets should cap agent loops and denial-of-wallet attacks. Maximum tool steps, token budgets, and timeouts can prevent one manipulated interaction from consuming excessive resources.<\/p>\n
Human approval interfaces should display exact side effects, target resources, and supporting evidence. Vague confirmations such as \u201capprove agent plan\u201d do not provide meaningful oversight.<\/p>\n
Network egress controls can prevent compromised agents or tools from sending data to arbitrary destinations. Approved gateways or allowlists should reflect the application\u2019s actual external dependencies.<\/p>\n
Secrets should be retrieved at runtime from controlled stores or workload identity systems. Prompt text, model files, notebooks, and container layers are poor places for long-lived credentials.<\/p>\n
Observability should record control decisions: authentication result, retrieval filters, guardrail interventions, tool authorization, human approvals, model\/prompt version, and output-policy actions.<\/p>\n
Security monitoring should alert on changes to the controls themselves. Unauthorized guardrail edits, new tool permissions, vector-store policies, or model-registry roles can weaken protection silently.<\/p>\n
Control testing should include failure modes. Ask what happens if the guardrail service is unavailable, the identity provider fails, retrieval permissions cannot be checked, or the audit pipeline is delayed.<\/p>\n
High-risk systems should fail safely. For example, a financial agent might preserve read-only information while disabling transactions if approval or policy services are unavailable.<\/p>\n
Independent assurance can sample actual production evidence to confirm controls operate as designed. The presence of a policy document or architecture diagram is not proof that authorization and monitoring work.<\/p>\n
Control exceptions should have scope, owner, reason, compensating controls, and expiry. If many systems need the same exception, the reference architecture or policy may need redesign.<\/p>\n
Enterprise AI security is strongest when controls reinforce each other: identity limits authority, data controls limit exposure, model controls limit unsafe behavior, tool controls limit impact, and monitoring makes failures visible.<\/p>\n
Enterprise control frameworks should map AI safeguards into familiar categories such as preventive, detective, corrective, compensating, and recovery controls. This helps risk owners understand how new AI controls relate to established cybersecurity practice.<\/p>\n
Preventive controls include least privilege, source allowlists, signed artifacts, retrieval filters, and tool restrictions. Detective controls include prompt-attack monitoring, abnormal access alerts, and model-behavior evaluation.<\/p>\n
Corrective controls include rollback, credential rotation, model revocation, and corpus cleanup. Recovery controls restore trusted models, data, and infrastructure after compromise.<\/p>\n
Controls should be layered so failure of one does not create unrestricted access. A missed prompt injection should still encounter retrieval authorization and tool permission.<\/p>\n
AI platforms should separate control-plane APIs from end-user inference. Model upload, prompt editing, guardrail administration, and tool registration deserve stronger privilege than normal user requests.<\/p>\n
Administrative changes should be logged and ideally require peer review for high-risk systems.<\/p>\n
Secure defaults reduce review effort. New projects should start with logging, encryption, private data access, least-privilege roles, and bounded model settings enabled rather than relying on teams to add them later.<\/p>\n
Model-access policies can restrict which teams use expensive or high-capability models, reducing both security and cost risk.<\/p>\n
Evaluation should include control bypass attempts. Testing only model quality does not reveal whether users can retrieve another tenant\u2019s document, invoke a write tool, or manipulate a memory store.<\/p>\n
Agent memory needs its own controls for scope, retention, deletion, and sensitive content. Memory can become a long-lived data store even when the original chat is temporary.<\/p>\n
Browser and code-execution tools should use sandboxing and network restrictions. Arbitrary browsing or code execution expands both attack surface and exfiltration paths.<\/p>\n
Human oversight should be targeted at decisions where people can realistically add judgment. Low-risk repetitive actions can remain automated if deterministic controls are strong.<\/p>\n
Model outputs should be treated as untrusted content when rendered into web pages, commands, SQL, configuration, or code. Output validation prevents LLM mistakes from becoming injection vulnerabilities.<\/p>\n
Control maturity should be measured with tests. For example, verify that unauthorized retrieval fails, a revoked model cannot deploy, and a disabled tool becomes unavailable immediately.<\/p>\n
Tabletop exercises can test governance and response when technical controls fail, such as a provider outage or accidental exposure of a sensitive knowledge source.<\/p>\n
Independent audit can examine evidence such as configuration, logs, approvals, and test results to determine whether documented controls operate consistently.<\/p>\n
AI control libraries should be reviewed as providers add features. Native guardrails, evaluation, private networking, and identity options can reduce the need for custom controls over time.<\/p>\n
Custom controls should still be justified where they address organization-specific risks or integrate enterprise policy more effectively.<\/p>\n
The best enterprise control system gives builders a secure default path and gives security leaders confidence that deviations are visible, tested, and accountable.<\/p>\n
Security controls should also address availability and cost abuse. Long prompts, recursive agents, expensive model routes, repeated tool retries, and oversized files can create denial-of-wallet or quota exhaustion without exploiting a traditional vulnerability.<\/p>\n
Set request limits, tenant quotas, maximum execution steps, timeout policy, and anomaly alerts based on business value. These controls protect both availability and budget.<\/p>\n
Control ownership should be explicit. Identity teams, platform teams, model teams, data owners, security operations, and privacy teams may each operate different safeguards. A control with no operational owner will eventually drift.<\/p>\n
Runbooks should define what happens when a control fails. If a vector filter, guardrail, or approval system is unavailable, the application should enter a known degraded mode rather than silently bypass the control.<\/p>\n
Security architecture should also support rapid revocation. Teams need to disable one tool, model version, identity, knowledge source, or prompt configuration without rebuilding the entire system.<\/p>\n
Control evidence should remain available for incident review and audit: configuration versions, policy changes, evaluation results, logs, exception approvals, and restore tests.<\/p>\n
The long-term objective is measurable defense in depth. Each layer has a defined purpose, independent enforcement where practical, and enough telemetry to prove whether it worked when the system faced real misuse.<\/p>\n
Control maturity also depends on configuration consistency across environments. Development may permit broader experimentation, but staging and production should inherit the approved security baseline through automated deployment rather than manual hardening.<\/p>\n
Security testing should verify that lower environments cannot reach production data or tools accidentally. Shared credentials and permissive network routes often erase the separation teams believe they have.<\/p>\n
Enterprise control catalogs should map each safeguard to risk scenarios and evidence sources. This helps owners understand why a control exists and what data proves it is operating effectively.<\/p>\n
Control design should also include decommissioning. Retire old model endpoints, tool permissions, service identities, prompt versions, vector indexes, and security exceptions when the feature is no longer supported.<\/p>\n
Stale AI resources can remain accessible and billable long after users stop seeing them, creating hidden attack surface and governance debt.<\/p>\n","protected":false},"excerpt":{"rendered":"
Enterprise AI security requires controls at several layers because no single guardrail can protect data, models, users, tools, and infrastructure simultaneously. Effective control design combines […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"et_vendor":[31],"et_program":[83],"et_certification":[],"et_exam":[204],"et_topic":[236,270],"class_list":["post-3058","post","type-post","status-publish","format-standard","hentry","category-post","et_vendor-isaca","et_topic-governance-risk","et_topic-it-governance-and-audit"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts\/3058","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/comments?post=3058"}],"version-history":[{"count":4,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts\/3058\/revisions"}],"predecessor-version":[{"id":6412,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/posts\/3058\/revisions\/6412"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/media?parent=3058"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/categories?post=3058"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/tags?post=3058"},{"taxonomy":"et_vendor","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_vendor?post=3058"},{"taxonomy":"et_program","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_program?post=3058"},{"taxonomy":"et_certification","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_certification?post=3058"},{"taxonomy":"et_exam","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_exam?post=3058"},{"taxonomy":"et_topic","embeddable":true,"href":"https:\/\/www.exam-topics.com\/blog\/wp-json\/wp\/v2\/et_topic?post=3058"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}