AI 보안

It includes ordinary software security and threats that target learning or model behavior. A secure design begins with the assets, adversaries, and trust boundaries of the actual application.

주요 시사점

• Threat-model the full application.
• Enforce permissions outside the model.
• Retest controls across system changes.

Identify what needs protection: private inputs, training data, model artifacts, credentials, connected accounts, and external actions. Record who can influence each input and what an attacker could gain from a failure. A public chatbot and an internal agent with write access have different threat models. Threats can affect different stages. Poisoned training material can alter learned behavior; adversarial inputs can manipulate predictions; untrusted retrieved content can redirect a tool-using application. Model output can also become dangerous when inserted into a database query, webpage, or command without appropriate handling. Apply controls at the software boundary. Enforce authorization in code, keep secrets out of model-visible context where possible, restrict tool scope, and validate outputs before use. A prompt asking a model to behave safely cannot replace account isolation or permission checks. Test representative failure paths in an authorized environment and maintain an incident process. Log enough information to investigate without collecting unnecessary sensitive content. Evaluate controls after changes to the model, retrieval sources, tools, and dependencies. Describe residual risk honestly; no single filter establishes complete protection.

1. Imagine an assistant searching a private document store for a signed-in user.
2. Apply the user’s access filter in the retrieval service before documents enter the model context.
3. Test with a document belonging to a different account and verify that neither its contents nor identifying metadata appear in the result.

This defensive, hypothetical test checks authorization independently of the model’s willingness to follow instructions.