How to Build an AI Security Framework

An AI security framework organizes protection across the infrastructure supporting AI, AI-specific risks, and sector-specific requirements, following the layered approach described in the Framework for AI Cybersecurity Practices. For enterprise implementation, turn those categories into system-specific rules for data access, permitted actions, release evidence, and incident ownership. Start with one business process and approve only the paths your team can test and operate.

Key takeaways

• Define the business process, authorized data, permitted actions, and accountable owner before selecting technical controls.
• Require separate approval for introducing real data and enabling recurring production actions.
• Attach release evidence to the exact system version, permissions, and provider path being approved.
• Treat human approval as a specific enforced control, with a named reviewer and a failure procedure.
• Reopen the relevant security review whenever a change expands access, action authority, or processing scope.

Choose reference frameworks by the decisions you need to make

The NIST AI Risk Management Framework addresses risk across the design, development, use, and evaluation of AI systems, with an approach intended to work across sectors, according to this explanation of its scope. Organize your risk questions around the stages that apply to your proposed system. Then assign a concrete deliverable to each question: an access test, an approval policy, a release record, or an operating procedure.

For technical coverage, the Framework for AI Cybersecurity Practices separates foundational cybersecurity, AI-specific cybersecurity, and sector-specific cybersecurity. Use those layers to check whether your review covers the surrounding infrastructure as well as the AI components. Ask your risk and legal owners to identify which sector requirements need separate assessment. Have them document what still needs review before your team accepts the general framework as sufficient.

State which decisions each internal AI framework governs and who must make them. An AI adoption framework should guide the choice of work to introduce and identify who must adopt it. An AI development framework should cover design and testing; an AI implementation framework should govern deployment and operational handover. Require the security review to follow the same system through all three. Keep one shared release record so each team works from the same description of what was approved.

When a supplier maps its controls to a framework, ask your team to check whether that framework helps answer a release question: which data path or action is authorized, on what evidence, and by whom? A supplier's mapping alone should not determine your choice. Choose the reference material that helps your team make and document those decisions.

Define the system boundary before assigning controls

Begin with a short system charter. State the intended business result and the operational perimeter, meaning the process, people, tools, data, and actions included in the release. Write exclusions with the same precision as permissions.

Include the following fields in the charter so reviewers can inspect the proposed scope:

• The business result and the process owner accountable for acceptance.
• The authorized users, reviewers, and service identities.
• The source systems, receiving systems, providers, and processing regions.
• The permitted data categories and retention rules.
• The allowed, approval-gated, and prohibited actions.
• The failure conditions, manual fallback, and operating limits.

At Compsia, we define the exact data, sources, actions, owners, controls, acceptance tests, and operating limits for each custom AI production system. Where evidence is incomplete, we narrow or validate the path before production. Our approach to system-specific trust and claims is the relevant reference for that boundary.

Assign authority for approval, stopping, and recovery

Give the process owner authority to accept the business behavior and residual limitations. Assign IT ownership of identities, integrations, credentials, and environments. Ask security and privacy owners to approve their respective boundaries, then name an operating owner who can stop processing and initiate recovery.

Record a backup for each operational responsibility. For every approval, specify what the approver must inspect and what happens when that person is unavailable. Do not authorize production until someone has accepted responsibility for the fallback process as well as the AI system.

Separate the real-data gate from the action gate

Use two release decisions: permission to process real data and permission to take recurring production actions. Compsia's internal release standard separates those decisions and requires system-specific evidence for each. The two-gate production security checklist provides a companion review structure.

Approve the full data path before using real data

Before introducing real data, document the applicable processing agreement, provider and subprocessor records, regions, authorized data categories, and retention rules. Test scoped accounts against both permitted and prohibited access. Assign an incident owner and test the export, return, and deletion-verification procedures.

Include prompts, retrieved excerpts, application logs, support access, and exports in the review wherever the proposed design uses them. Do not approve a path whose copies or receiving systems remain unspecified. Until approval, use genuinely de-identified test material and keep production connections disabled.

Human review does not waive Compsia's privacy, access, retention, incident, or confidentiality requirements. Apply the same rule in your release process: requiring a reviewer should not create an exception to the data gate. Document the reviewer's own access and the location where they inspect the output.

Approve side effects only after testing their enforcement

For an action-capable release, start with denied actions and allow only the exact operations required. Separate creating a draft from sending it, proposing an update from committing it, and reading a record from changing it. Enforce those distinctions in credentials and application controls. Written instructions alone should not be accepted as enforcement of the approved action boundaries.

Require authenticated, attributable approval for consequential actions. Bind approval to the exact proposed action and material inputs, then reject execution if either changes. Use a defined expiry for pending approvals and require a fresh review after expiry.

Test duplicate execution, retries, partial failure, and rollback before release. For example, require a repeated request to reuse an operation identifier rather than create a second write. Use the AI write-access permission model when deciding which operations should remain prohibited, approval-gated, or narrowly permitted.

Use a release record to connect tests, owners, and changes

Create one release record for the exact deployment version under review. Include its environment, provider path, access scopes, action policy, acceptance tests, failure tests, and unresolved limitations. Require the approving owners to sign against that version.

Research on agentic AI identifies risks including memory poisoning, cascading failures, and oversight evasion, according to this survey of agentic AI and cybersecurity. Where your design uses persistent state or linked actions, translate those risk categories into tests. Check the behavior your system permits, and document which research risks apply to that behavior. Assess their relevance to the deployment before assigning tests.

Use a test set with observable pass conditions:

• An unauthorized user receives neither restricted content nor an action based on that content.
• Instructions embedded in an input do not expand tool permissions or approval authority.
• A revoked permission prevents the next protected access.
• A changed action payload requires new approval.
• A repeated execution request does not create an unintended duplicate write.
• A failed downstream step produces a visible exception and a usable recovery procedure.

For every failed test, record the owner, corrective action, and release decision. Distinguish an accepted limitation from an untested behavior. If the team cannot demonstrate a required boundary, remove that path from the release or hold the release.

Decide in advance which changes reopen approval

Set a change rule based on what the system can access and do. Require renewed review for a new data category, receiving system, provider path, business unit, or action permission. Also reassess model, prompt, and configuration changes against the tests relevant to their possible effects.

Attach an invalidation condition to each material piece of evidence. An access test, for example, should name the roles and configuration it covers. If either changes, require the owner to confirm whether that evidence still supports the release.

Work through a request-triage release before allowing record updates

Consider an internal request queue where the proposed AI component would classify requests, retrieve approved guidance, and draft routing recommendations. Limit the first release to preparing those recommendations for the operating team to review. Keep final routing and source-record changes with the operating team.

Authorize only the intake fields and guidance sources needed for that task. Require each recommendation to identify the source version used and route ambiguous requests to a named reviewer. Test conflicting instructions, missing fields, restricted documents, and unavailable source systems before acceptance.

For the next release, propose one bounded action: updating a designated routing field after approval. Require the reviewer to see the target record, proposed value, and supporting source. Bind the approval to that payload and reject the action if the underlying record changes before execution.

Test a partial failure in which the routing update succeeds but the confirmation step fails. Require the operator to inspect the existing operation status before retrying. Accept the release only when the team can distinguish a failed action from a successful action with a failed confirmation.

Record what remains excluded, such as external communications or changes to unrelated fields. Evaluate those capabilities separately, and make sure a broad permission to update records does not authorize the excluded operations. This gives the process owner an explicit expansion decision after the initial operating behavior has been accepted.

Choose narrower authority when review and recovery are insufficient

Before choosing action-capable operation, ask the operating team to perform the proposed review using production-like inputs. Require reviewers to identify the intended action, inspect its supporting evidence, reject it when necessary, and explain the recovery procedure. If they cannot complete those tasks reliably during testing, keep that action outside the release.

Balance the review burden against the scope of permitted action. For a reversible, low-consequence update, evaluate a narrow allowlist with exception handling. For a consequential or difficult-to-reverse action, retain authenticated approval or leave execution with the operating team until the required evidence supports another choice.

Make the stop behavior explicit. Decide whether stopping means disabling writes, revoking credentials, pausing all processing, or moving work to a manual queue. Assign responsibility for unfinished work and specify how the team will reconcile it before restarting.

Use three release outcomes: proceed within the tested scope, narrow the scope, or defer. Choose narrowing when a useful recommendation-only release can meet the business need. Defer when required access, ownership, or recovery cannot be established.

Frequently asked questions

How is an AI security framework different from an AI risk framework?

For planning purposes, use the security framework to organize protection of data, identities, infrastructure, and actions. Use the broader risk review to assess additional harms and operating consequences. The risk management framework explanation describes risks to people, organizations, and ecosystems, so avoid reducing that review to a security checklist.

Can we use the framework when buying AI software rather than building it?

Apply the same release questions to the exact configuration you intend to use. Ask for evidence covering its data path, access model, permitted actions, retention, and failure behavior. If required evidence is unavailable, restrict the proposed use or defer approval. Do not accept a general supplier statement as evidence for the configuration under review.

Who should own the AI security framework?

Assign an executive owner for the enterprise standard and a named system owner for each deployment. Give security, privacy, IT, and operations explicit approval responsibilities within their scope. Name the person authorized to stop the system without waiting for a committee meeting.

How often should we review a deployed AI system?

Set a scheduled operating review and require additional review when the approved boundary changes. Define triggers for new data, access scopes, providers, receiving systems, and action permissions. After an incident or failed control test, reassess the affected release evidence before restoring the relevant capability.

Select one system for a release decision

Choose a proposed deployment and ask its owner to prepare the system charter, data-path record, action policy, failure tests, and fallback procedure. Decide whether the evidence supports release, a narrower scope, or a hold.

For a custom AI production system, review how Compsia designs, launches, and operates the complete system. Bring the process you want to improve and identify who can accept its operating boundaries. We look at how your team runs its core processes and show you what we would make more efficient.