Does a model safety filter provide security?

It may contribute to a defense, but it does not replace authentication, authorization, isolation, and other system controls.

Is an AI model itself the only asset to protect?

No. Data, credentials, tools, logs, infrastructure, and the development pipeline also matter.

Can security be proven by one benchmark?

A benchmark provides evidence within its scope. Security claims must state the environment, adversary capabilities, and limitations of the evidence.

AI Glossary / Governance, ethics and safety / Intermediate

Security

Definition

Security is the protection of systems and information against unauthorized access, use, alteration, disruption, or other harmful interference. For AI, it includes protecting data, models, software, credentials, and connected tools, while preserving confidentiality, integrity, and availability. It concerns the complete operating environment, not just whether a model refuses an unsafe request.

What it means

Confidentiality concerns who may access information. Integrity concerns whether information and system behavior are protected from unauthorized changes. Availability concerns whether authorized users can obtain needed services. An AI assistant can fail on any of these dimensions even if its ordinary answers are accurate.
AI introduces additional pathways for interference, such as malicious instructions embedded in retrieved content, manipulated training data, and attempts to extract restricted information through a model interface. Established security practices remain necessary alongside defenses tailored to these behaviors. A model's conversational promise is not an access-control mechanism.

How it works

Identify assets, authorized users, trust boundaries, and the actions the system can perform. Consider how an adversary might reach data or capabilities through interfaces, dependencies, documents, or accounts. Apply appropriate controls, such as authentication, authorization, limited tool permissions, secure configuration, input handling, monitoring, and response procedures.
Test whether controls remain effective under relevant misuse scenarios. Protect the development and deployment pipeline as well as the running service. Track changes to models, data sources, and integrations because they can alter the attack surface. Security work includes prevention, detection, response, and recovery; a blocked attack in one test does not establish permanent protection.

Three practical examples

A retrieval assistant checks a user's permission before returning material from an internal document store.
A team verifies the origin and integrity of model artifacts before promoting them into its production pipeline.
An agent's tool account can draft a record but cannot approve or execute the consequential action, limiting what a compromised interaction can accomplish.

Think of it this way

Think of an office building with identity checks, room permissions, protected records, alarms, and incident procedures. A helpful receptionist does not replace those controls. The analogy is limited because an AI system can transform and combine information across many digital paths, so every relevant interface and dependency must be considered rather than only the front door.

Worked example

A fictional organization gives an assistant access to 300 documents: 240 public-to-staff documents and 60 restricted records. A test user is authorized only for the first group. In 100 controlled requests targeting restricted content, the retrieval layer refuses all 100 unauthorized retrievals.
That result supports a narrow finding about those retrieval checks. It does not show that the assistant has no other disclosure route. The team must consider cached outputs, logs, shared conversation state, exports, and information that might already be present elsewhere. If a later integration gives the agent an unrestricted search account, the original result does not automatically transfer. The example demonstrates testing a trust boundary, not a claim of complete confidentiality or a recommended test sample size.

Illustrative case study

At fictional Maple Operations, an assistant summarizes supplier files. A controlled test places misleading instructions inside a test document and asks the assistant to send information through a connected tool. Reviewers discover that the tool account has broader permissions than the task requires.
The team narrows permissions, separates document content from action authority, and checks the surrounding controls again. It records the remaining assumptions and incident response route. This fictional case illustrates defense in depth without claiming that any particular prompt or permission setting eliminates every possible attack.

Common misconceptions and mistakes

Security is not identical to privacy. Information can be securely stored and still be collected or used inappropriately. Safety is also distinct: a secure system can cause harm through ordinary operation or an unsuitable objective.
Do not assume that an internal network, encryption, or a model refusal settles every security question. Encryption protects particular paths or storage states, while authorization determines who may use information. Likewise, a successful red-team test can reveal a weakness, but failure to find one is limited by the tests performed. Controls must be evaluated against the actual threat model and system configuration.

Business use

Security requirements help organizations decide what an AI service may access and do. They influence architecture, procurement, release approval, monitoring, and incident ownership. Business owners should be able to identify sensitive assets, authorized uses, and the consequences of compromise. Changes that expand an agent's authority deserve review because they can turn an incorrect response into an unauthorized action.

Check your understanding

An assistant is instructed never to open restricted records, but its tool account can read them without checking the user's permissions. Is the instruction sufficient access control?

Answer: No. Enforced authorization is needed at the relevant boundary. A language instruction alone does not reliably constrain what the tool permits.

Related terms

Learn next

Draw the trust boundaries around an AI workflow. Mark where user identity is checked, where permissions are enforced, and which data or tools each component can reach. Then trace a hypothetical unauthorized request through the workflow to identify controls that rely only on the model's cooperation.

Sources

Sources: NIST AI RMF, secure and resilient systems: https://airc.nist.gov/airmf-resources/airmf/3-sec-characteristics/ . NIST Cybersecurity Framework: https://www.nist.gov/cyberframework . NIST CSRC, least privilege: https://csrc.nist.gov/glossary/term/least_privilege . NIST, Adversarial Machine Learning taxonomy: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf .

Previous: Secular variation Next: Seed pattern in IE