AIを搭載したSaaSプラットフォームを公開することは、単に新しい機能を追加することではありません。製品全体のセキュリティモデルそのものを変化させます。
従来のSaaSアプリケーションでも、認証、認可、テナント分離、API、機密データ、セッション、インフラ、ビジネスロジックを保護する必要があります。LLMを追加しても、これらの要件がなくなるわけではありません。
むしろ、信頼できない自然言語を処理し、非公開情報を取得し、ツールを選択し、場合によっては既存アプリケーション上で操作を開始できる、新しい意思決定レイヤーが追加されます。
その結果、攻撃対象領域はより大きく、より複雑に接続されたものになります。
ユーザーは単純なチャット画面とやり取りしているだけに見えても、その裏では複数のAPIへアクセスし、Vector Databaseから文書を取得し、会話メモリを保存し、AI Agent経由でツールを呼び出している可能性があります。
つまり一つの会話リクエストが、通常のアプリケーションリクエストより多くのセキュリティ境界を横断する可能性があります。
OWASPのGenAIセキュリティガイダンスでは、Prompt Injection、Sensitive Information Disclosure、Excessive AgencyなどのLLM固有リスクを従来のApplication Securityと組み合わせて評価しています。またAgentic Security Initiativeでは、複雑なワークフローを計画し、自律的に操作できるAIシステムまでThreat Modelを拡大しています。
本番公開を控えるSaaS企業にとって、これはAIセキュリティを最後に実施するPrompt Engineeringレビューとして扱うべきではないことを意味します。
AIセキュリティは、最初から製品アーキテクチャの一部である必要があります。
強力なPre-Launch Security Assessmentでは、認証済みユーザーが正しいTenantのデータだけへアクセスできるか、信頼できないコンテンツがAgent Actionへ影響できるか、Toolが独立してPermissionを強制しているか、Sensitive DataがModel Context経由で流出しないか、予期しないAI挙動がDeterministic Application Controlsによって封じ込められるかを確認します。
重要な質問は、
「通常のテストでAIは正しく動作するか？」
ではありません。
本当に確認すべきなのは、
「敵対的な条件下でAIが間違った判断をした場合、何が起こるのか？」
です。
なぜAIはSaaSのセキュリティモデルを変えるのか
SaaSセキュリティは、本質的に境界の管理です。
ある顧客が別の顧客のレコードへアクセスしてはいけません。
一般ユーザーが管理者機能を利用できてはいけません。
Public APIが内部データを公開してはいけません。
Backend Serviceが未認証リクエストを信頼してはいけません。
機密操作はAuthorization後にのみ実行される必要があります。
AIは、この決定論的な境界の中に部分的に確率的な挙動をするコンポーネントを導入します。
だからといって、モデルそのものをAuthorization Systemにする必要はありません。
むしろその逆です。
OWASPのExcessive Agencyに関するガイダンスでも、モデルが利用できる機能とPermissionを最小化し、機密操作の認可をLLMへ委ねるのではなく、Downstream System側で強制することが推奨されています。
この役割分離は、最初のArchitecture Designから反映されるべきです。
AIはUser Intentを解釈できます。
ユーザーがどの操作を望んでいるか推測できます。
Functionを選択できます。
しかし、そのAuthenticated Identityが本当にそのActionを実行できるかを決めるのはアプリケーションです。
この責任が分離されていれば、AIはアプリケーションの一つのコンポーネントにとどまります。
両者が混ざると、モデルが既存のSecurity Modelを回避する経路になる可能性があります。
Pre-Launch Reviewはモデル単体ではなくAI機能全体から始める
よくある間違いは、モデルだけを評価することです。
禁止されたRequestを拒否できるか確認する。
System Promptが隠れたままか確認する。
Output Qualityを評価する。
こうしたテストも役立ちます。
しかし、SaaSアプリケーション全体のセキュリティを説明するものではありません。
OWASPのSecuring Agentic Applications Guideも、LLMそのものだけではなく、LLMを中心に構築された広いアプリケーション全体を対象にしています。
そのThreat Modelには、Agent、Tool、Permission、Data、Runtime Behaviorが含まれます。
そのためPre-Launch Security Teamは、AI Workflow全体をマッピングする必要があります。
User Inputはどこから入るのか。
どのModelが受け取るのか。
どのSystem Instructionが追加されるのか。
どのConversation Stateが保存されるのか。
モデルはDocumentを取得できるのか。
どのDatabaseを検索するのか。
どのAPIを呼び出せるのか。
どのExternal Toolが利用可能か。
Application Stateを変更できるか。
外部へ通信できるか。
どのCredentialを使用するか。
Dataがモデルへ到達する前に、どのAuthorization Checkが行われるか。
これらの答えが、本当のAttack Surfaceを示します。
機密統合を持たないChatbotは比較的小さなImpact Boundaryしか持たないかもしれません。
一方、CRM Record、Payment Information、Email、Account Management Toolへ接続されたCustomer Support Agentは、同じFoundation Modelを使っていてもはるかに大きなリスクを持ちます。
Authenticationは今後も出発点でなければならない
ユーザー向けAI機能には、SaaSプラットフォームの他の部分と同じIdentity Disciplineが必要です。
アプリケーションは誰がリクエストを開始したのかを把握し、そのIdentityをDownstream Operationまで維持する必要があります。
問題は、FrontendではAuthenticationが正常に存在しているのに、AI Workflowへ入った瞬間にUser Identityが失われる場合によく発生します。
ユーザーがログインする。
RequestがAI Orchestration Serviceへ入る。
AgentがShared Service Accountを使ってBackendを呼び出す。
Backendから見えるのはAI Service Identityだけ。
元ユーザーのPermissionが他の場所で再度強制されなければ、AI Layerはユーザー自身よりも広いAuthorityを持つことになります。
SaaSでは特に危険です。
Tenant Isolationは、どのOrganizationのどのUserがRequestを送っているかを正確に把握することに依存するからです。
AI機能を追加しても、既存のAuthenticationとAuthorization Boundaryを弱めてはいけません。
Tenant IsolationはAI SaaSで最優先すべきリスクの一つ
Multi-Tenant SaaSは、共有Infrastructure内に複数組織のデータを保存します。
Tenant Isolationは、一つの顧客が他の顧客のDataやActionへアクセスすることを防ぎます。
AIは複数箇所でこのIsolationを偶発的に弱める可能性があります。
RAG RetrievalがShared Vector Databaseを検索する。
Conversation Memoryが複数ユーザーで共有される。
Agent ToolがGlobal CredentialでBackendへアクセスする。
Internal APIが通常のUser Interfaceより多くのデータを返す。
Cacheが異なるAuthorization Context間で結果を再利用する。
その結果、これまで分離されていた複数のData SourceがLanguage Model内部で合流する可能性があります。
そのためCross-Tenant Leakageは、ローンチ前に最優先で検証すべきシナリオの一つです。
Tenant Contextは、Authentication、Authorization、Query、Cache、Storageのすべてで維持する必要があります。
AIが間に入っても同じです。
Tenant Aの情報が、最初からTenant BのModel Contextへ入ってはいけません。
すべてのデータを取得してから、
「他の組織のデータは公開しないこと」
とLLMへ指示する設計は避けるべきです。
AuthorizationはModelがDataを受け取る前に実行されるべきです。
AuthorizationはRetrievalより前に実行する
RAGは、SaaS製品が最初に導入するAI機能の一つになりやすい技術です。
ユーザーが自社のBusiness Dataに対して自然言語で質問できるからです。
しかしSecurity Modelは、RelevanceとPermissionを明確に分ける必要があります。
Vector Searchが答える質問は、
「このQueryと意味的に関連するDocumentはどれか？」
です。
Authorizationが答える質問は、
「このUserがアクセスを許可されているDocumentはどれか？」
です。
この二つを同じものとして扱うことはできません。
Vector Storeが別顧客のDocumentを非常に関連性が高いと判断する場合があります。
それでも、そのDocumentへのAccess Permissionが生まれるわけではありません。
より安全なArchitectureでは、まずTenantとUser Permissionによって検索対象Data Setを制限し、その後にSemantic RetrievalでAuthorized Documentsの中からRelevant Documentを選択します。
RAGは、許可されたKnowledge Accessを便利にするものであるべきです。
RAGそのものがAuthorizationを拡張してはいけません。
Prompt Injectionは「発生する可能性がある攻撃条件」として扱う
信頼されていない自然言語がLLM Contextへ入る製品では、Prompt InjectionをLaunch Threat Modelへ含める必要があります。
直接攻撃だけではありません。
SaaSではIndirect Prompt Injectionが特に重要です。
攻撃者自身がAI Assistantへ直接話しかけなくても攻撃できる可能性があります。
Support Ticketを操作する。
Documentを作る。
CRM Recordを入力する。
Web Pageを用意する。
Customer Uploaded Fileを作る。
Emailを送る。
その後、正規ユーザーがAIにその情報を処理させます。
Attacker-Controlled ContentがModel Contextへ入り、次に起こるActionへ影響しようとします。
これは従来のSaaSでは珍しいSecurity Propertyを生みます。
AIが消費するDataを制御できる人物が、自分では直接開始していないWorkflowへ影響できる可能性がある。
公開前に、どのData SourceがModel Contextへ入る可能性があるかを明確化し、Trust Levelを分類する必要があります。
Internal System InstructionとCustomer Uploaded Documentを、暗黙的に同じAuthorityとして扱ってはいけません。
Prompt Injectionの深刻度はAIが何へ到達できるかで決まる
単純なFAQ AssistantへのPrompt Injectionでは、主な影響はGenerated Textだけかもしれません。
一方、Database AccessやState-Changing Toolを持つAgentが同じ操作を受けた場合、はるかに重大になります。
そのためPrompt Injectionの評価では、モデルが変なInstructionへ従ったかだけを見るべきではありません。
Attack Pathを最後まで追跡します。
操作されたAIがConfidential Informationを公開できるか。
別Toolを選べるか。
情報をOrganization外へ送れるか。
Recordを変更できるか。
User Permissionを超えたOperationを実行できるか。
Deterministic Controlがこれらの結果を止めるなら、モデルの推論自体が操作可能でもApplication全体ははるかにResilientです。
これがDefense in Depthです。
Sensitive DataはModel Contextへ入る前に最小化する
AIアプリケーションは、モデルが実際に必要とする以上の情報を受け取っている場合があります。
Backendが実装を簡単にするためCustomer Object全体を取得する。
モデルが使うのは3つのFieldだけ。
残り30個のFieldもContextへ残る。
これはPrompt Injection、Logging Error、Accidental DisclosureのImpactを増大させます。
SaaSではData Minimization自体が実用的なSecurity Controlです。
AIがSubscription Statusだけ必要なら、Subscription Statusだけを渡す。
Project NameとDeadlineだけ必要なら、Internal Financial Recordまで自動的に渡さない。
一つのAuthorized Documentについて質問しているなら、無関係なConfidential InformationでContext Windowを埋めない。
必要最小限のContextが、最小のDisclosure Surfaceを作ります。
Cross-Tenant Dataを「念のため」Contextへ入れてはいけない
共有SaaS Infrastructureでは特に重要です。
Developerは、
「他のOrganizationのDataは絶対に公開しない」
という強いSystem InstructionがSecurity Boundaryになると考えるかもしれません。
なりません。
現在のUser Contextに別Tenantの機密情報が存在する時点で、Architectureはすでに危険な境界を越えています。
モデルが通常は正しく振る舞っているかもしれません。
Securityをその通常動作へ依存させてはいけません。
Unauthorized Dataが最初からModelへ到達しないArchitectureの方が、Confidentialityははるかに強力です。
Toolを持つSaaS Agentは個別のSecurity Reviewが必要
AIがFunctionを呼べるようになると、Security Modelは大きく変わります。
最初はProduct Questionへ回答するだけのSaaS Chatbotだった。
次にCustomer Recordへ接続する。
その次にSupport Ticket。
Email。
Billing。
最終的には、AIが重要なBusiness Operationを実行できるようになります。
この段階では、Tool SecurityはPrompt Securityと同じくらい重要です。
Pre-Launch Teamは、モデルがアクセスできるすべてのToolを特定し、
「もしモデルがこのToolを間違って選んだら、何が起こるか？」
を確認する必要があります。
AI ToolはLeast Privilegeで動作させる
Toolには、その目的を達成するために必要なCapabilityだけを与えるべきです。
Subscription Informationを読むだけのAssistantにSubscription Cancellation Permissionは不要です。
Documentを読むだけのAssistantにDeletion Capabilityを与える必要はありません。
Code Analysis AgentがProduction Deployment Authorityまで持つ必要もありません。
Agentが利用できるCapabilityが少ないほど、Manipulationが発生した場合のImpactも小さくなります。
これは、モデルが完璧に動作することを前提とせずに利用できる非常に強力なArchitecture Controlです。
AIが間違ってもよい。
Capability Boundaryが結果を制限します。
Read OperationとWrite Operationを分離する
ReadとWriteへ同じControlを適用する必要はほとんどありません。
多くのSaaS AI Workflowでは、変更よりも読み取りの方がはるかに多く行われます。
これを利用して、日常的なRead Operationは使いやすくし、高ImpactなWrite Operationはより強く保護できます。
Support AgentはAccount Informationを自動的に読める。
しかしSecurity Setting変更には追加Authorizationが必要。
Document Assistantは確認なしでSearchできる。
しかしPublishやDeleteには強いControlを要求する。
すべてのTool Callを同じリスクとして扱うのではなく、Action Impactに応じてAgent Autonomyを設計すべきです。
Backend AuthorizationはAI Tool Callでも必ず残す
Tool Useが既存SaaS Permissionを回避する経路になってはいけません。
たとえばApplicationにCustomer Recordを更新するFunctionがあるとします。
ユーザーがAIへUpdateを依頼する。
モデルがToolを呼ぶ。
Backendは、そのAuthenticated Userがその特定Objectを変更するPermissionを持つかを確認する必要があります。
自然言語RequestはAuthorization Tokenではありません。
Model-Generated Tool CallもAuthorization Tokenではありません。
Trusted AI Service Accountも、元Userに同じAuthorityがある証明ではありません。
ここでAI SecurityとTraditional API Securityが合流します。
AI InterfaceもServer-Side Authorizationをそのまま継承する必要があります。
一つのGlobal AI Service Accountを避ける
AIプラットフォーム全体を、一つのGlobal Privileged Machine Identityで内部サービスへ接続する設計はよくあります。
開発は簡単になります。
しかしBlast Radiusは大きくなります。
すべてのAIユーザーが、自分自身よりはるかに広いAccessを持つ中間システムとやり取りすることになるからです。
BackendがUser-Level Permissionを維持せず、そのIntermediaryを全面的に信頼すれば、単なるModel ErrorがPrivilege Escalationに変わります。
より強いArchitectureでは、User Authorizationを適切にDelegationするか、Downstream Operation実行前に同等のPolicy Enforcementを行います。
原則は単純です。
AIを使うことでUserの実効Permissionが増えてはいけません。
Human Approvalは本当に意味のあるActionへ使う
Human-in-the-LoopはSensitive Agent Operationに有効です。
ただし、無害なLookupまで毎回承認させると逆効果になります。
大量のConfirmationはApproval Fatigueを引き起こします。
Userは内容を読まずクリックするようになります。
重要なのは、間違いが意味のあるImpactを生むOperationへAttentionを集中させることです。
External Communication。
Account Change。
Permission Change。
Financial Operation。
Destructive Action。
Production Modification。
こうしたOperationにはExplicit Reviewを要求する価値があります。
ただしApprovalはAuthorizationの上に置くべきです。
そもそもPermissionを持たないOperationを、User自身がApproveして実行可能にしてはいけません。
AI APIにも通常のAPI Securityが必要
AI SaaS Platformは多くのInternal APIを追加します。
Model Gateway。
Tool API。
Retrieval Service。
Memory Service。
Agent Orchestration Endpoint。
これらがInternal Systemからしか呼ばれないとしても、自動的にTrustedになるわけではありません。
Internal Tool APIはAuthorizationを確認する。
Retrieval EndpointはTenant Boundaryを強制する。
Model EndpointはAuthenticationとUsage Limitを強制する。
AI-Generated Parameterを受け取るServiceは、User-Generated Parameterと同じようにValidationする。
モデルもUntrusted Input Sourceの一つです。
AIが生成したParameterにも通常のValidationが必要
Function CallingではStructured JSONがよく使用されます。
これは有用です。
しかし十分ではありません。
ParameterがSchemaを満たしていても危険な場合があります。
Object IDは正しい形式でも別Tenantのものかもしれない。
URLは正しい形式でもInternal Management Serviceを指しているかもしれない。
数値は正しいTypeでもBusiness Limitを超えているかもしれない。
Filenameは正しいStringでもUnauthorized Locationを参照しているかもしれない。
Schema Validationが確認するのはStructureです。
AuthorizationとBusiness Validationが確認するのは、Operationが安全かどうかです。
ローンチ前には両方を検証する必要があります。
SaaS AIにはAbuse ControlとResource Controlが必要
AI Workloadは通常のApplication Requestより大幅に高コストになる可能性があります。
一つのUser RequestがLarge Modelを何度も呼び出し、大量のContextを取得し、複数のDownstream Toolを実行する場合があります。
そのためFinancial RiskとAvailability Riskが発生します。
Pre-Launch Controlでは、一つのAccountがどれほど多くのWorkを発生させられるかを考えるべきです。
一人のUserが無制限なAutonomous Loopを開始できないようにする。
一つのRequestが無制限なTool CallへFan-Outしないようにする。
一つのTenantがInference Resourceを不均衡に消費しないようにする。
Usage LimitはFrontend HTTP Request Countだけではなく、AI Architecture全体を考慮して設計する必要があります。
Agent Workflowには専用Budgetが必要
Agentic Systemでは従来型Rate Limitingがより複雑になります。
ユーザーが一つRequestを送る。
AgentがLLMを呼ぶ。
Search Toolを呼ぶ。
再びLLMを呼ぶ。
2つのAPIを呼ぶ。
もう一度LLMを呼ぶ。
失敗したStepをRetryする。
一つのUser Requestが、大きなInternal Workloadへ変化します。
そのためSecurity ControlではWorkflow Budgetを考える必要があります。
Maximum Reasoning Steps。
Maximum Tool Calls。
Maximum Expensive Operations。
Maximum Input / Context Volume。
Maximum Runtime。
これらはAvailabilityとCostを守るだけではありません。
Compromised AgentがMonitoring Systemに検出されるまでに実行できるActionの範囲も制限します。
File UploadはAI Attack Surfaceを広げる
多くのAI SaaS Applicationでは、Document、Spreadsheet、Codeなどを分析するためFile Uploadを受け付けます。
File Handlingには従来からSecurity Requirementがあります。
AIはさらに別の問題を追加します。
Upload DocumentにModel向けのMalicious Instructionが含まれているかもしれない。
Shared Knowledge Baseへ入るかもしれない。
Retrievalを通じて将来のUserへ影響するかもしれない。
ParsingやResource Consumption Problemを起こすかもしれない。
そのため、
「Uploadを受理したFile」
と、
「信頼できるSource」
を区別する必要があります。
Upload Validationを通過したからといって、そのFileをAgent Instructionとして信頼してよいわけではありません。
特にRAG SaaSでは、一つのUploadが多くの将来Conversationへ影響する可能性があります。
External ContentはUntrustedのまま扱う
同じ原則はWeb Browsing、Email、Support Ticket、Third-Party Integrationにも当てはまります。
取得されたContent自体は正当な情報かもしれません。
しかしAdversarial Languageを含んでいる可能性があります。
External TextによってPrivileged Application Actionが直接決まるArchitectureは避けるべきです。
モデルは外部情報をReasoningへ利用できます。
しかしSensitive Actionは、引き続きIndependent Authorizationを通過するべきです。
AI MemoryにはTenant IsolationとUser Isolationが必要
Persistent MemoryはAI製品を便利にします。
同時に、もう一つのShared Databaseになる可能性があります。
Agentは何を覚えるのか。
そのMemoryのOwnerは誰か。
誰が更新できるか。
一人のUser Memoryが別Userへ影響するか。
Malicious ContentがPersistentになれるか。
UserがOrganizationを離れた場合どうなるか。
これらは通常のData Governance問題をAI Stateへ適用したものです。
Multi-Tenant SaaSではMemory IsolationをDatabase Isolationと同じレベルで扱う必要があります。
便利なPersonalization FeatureがCross-User Information Channelになってはいけません。
Memory Poisoningをローンチ前に検討する
Persistent Agent MemoryはConfidentialityだけでなくIntegrity Problemも作ります。
Untrusted User ContentがLong-Term Memoryを書き換えられる場合、Malicious InstructionやFalse Informationが一つのConversationを超えて残る可能性があります。
Pre-Launch Testingでは、Memoryが単なるConversation Contextなのか、それとも将来のSystem Behaviorを変えるAuthorityを持つのか確認する必要があります。
Authorityが大きいほど、WriteとRetrievalに強いControlが必要です。
LoggingはConversationだけでなくActionまで記録する
多くのAI SaaS PlatformはPromptとResponseのLoggingから始めます。
Debugには便利です。
しかしAgentがActionを実行する場合、Incident Responseには不十分です。
Security Teamが知る必要があるのは、
どのUserがWorkflowを開始したか。
どのModelが動いたか。
どのToolが選ばれたか。
どのObjectへアクセスしたか。
どのAuthorization Decisionが行われたか。
最も有用なLogは、元のHuman ActionとDownstream Executionを接続します。
同時にAI LoggingそのものがPrivacy Riskを作ります。
PromptにはConfidential Customer Informationが含まれるかもしれません。
Tool OutputにはSensitive Recordが含まれるかもしれません。
Model ContextにはInternal Dataが含まれるかもしれません。
そのためLogにもData MinimizationとAccess Controlが必要です。
Raw Secretをログへ保存しない
API Key、Bearer Token、Credential、Sensitive Authentication Materialは通常のAI Logへ入れるべきではありません。
モデル自身も、通常これらのSecretを必要としません。
Backend ServiceがCredentialを保持し、LLMへSecretを公開せずAuthorized Operationを実行できます。
これはPrompt LeakageやDebug LogによるImpactを減らします。
AIによって、Secretが偶発的にコピーされる場所が増えただけです。
基本原則自体はSecure Application Developmentと同じです。
Model OutputをUntrusted Outputとして扱う
AI-Generated ResponseはUserへ表示されるだけとは限りません。
SoftwareがそのOutputを消費する場合があります。
こちらの方が特にSecurity Sensitiveです。
Model OutputがHTMLになる。
Database Inputになる。
API Parameterになる。
Commandになる。
別のProgrammatic Instructionになる。
この場合、通常のOutput Handling Controlが必要です。
モデルをTrusted Sanitizerとして扱ってはいけません。
通常のUntrusted User ValueにEncodingやValidationが必要なら、Model-Generated Contentにも同じ扱いが必要です。
Pre-Launch Testingには従来型Web Application Securityも含める
AI Security Reviewに集中しすぎて、通常のVulnerabilityを忘れてはいけません。
SaaS Applicationには今でもLoginがあります。
Sessionがあります。
Password Resetがあります。
Authorizationがあります。
APIがあります。
Business Logicがあります。
File Handlingがあります。
Cloud Infrastructureがあります。
AIを導入しても、これらの重要性は下がりません。
高度なPrompt Injection DefenseがあってもBroken Tenant Authorizationは補えません。
安全なModel EndpointがあってもExposed Admin APIは補えません。
完璧に分離されたVector DatabaseがあってもBroken Authenticationは補えません。
そのためローンチ前には、AI固有AssessmentだけでなくWeb Application Penetration TestingとAPI Security Testingも必要です。
巧妙なPromptを試す前にAuthenticationをテストする
AI Pentestでは、AIらしいAdversarial Promptから始めたくなります。
しかし強いAssessmentはArchitectureとPermissionから始まることが多いです。
AuthenticationをBypassできるか。
Sessionは安全か。
Role Transitionは正しいか。
UserがAdmin Endpointへ直接アクセスできないか。
一つのTenantが別TenantのObjectを変更できないか。
基本的Application Controlが壊れているなら、奇抜なModel Behaviorを探すことに多くの時間を使う価値はありません。
AI Securityの土台は今でもApplication Securityです。
AI Interface経由のCross-Tenant Accessをテストする
通常のAuthorization Test後に、同じ境界をNatural Language Workflowからも確認します。
Tenant AがAIへTenant Bについて質問できるか。
モデルが別Tenant Documentを取得できるか。
AgentがSearch経由でUnauthorized Objectを発見できるか。
MemoryがTenant間でInformationをLeakしないか。
Shared Tool CredentialがTenant CheckをBypassしないか。
重要なのは、モデルが変なResponseを返すことではありません。
SystemがTenant Boundaryを越えるかどうかです。
Direct / Indirect Prompt Injectionを両方テストする
Launch Assessmentでは、Attacker-Controlled Conversationと、AIが間接的に処理するAttacker-Controlled Contentの両方をテストします。
Direct Testingでは、Malicious UserがAssistantへ直接影響できるか確認します。
Indirect Testingでは、Document、RAG Source、External IntegrationのContentが後続Workflowへ影響できるか確認します。
特に、一人のUserがUploadした情報を後で別UserやAgentが処理するSaaSでは重要です。
TestingはControlledに行い、派手なPrompt Outputを集めることより、最終的なSecurity Boundaryを確認することへ集中すべきです。
Data Leakageをテストする
Model ContextへどのSensitive Informationが入り得るか、Unauthorized Userがそれを取得できるかを確認します。
対象にはCustomer Data、Internal Application Metadata、System Instruction、RAG Document、Conversation Memory、Tool Result、Sensitive Error Informationなどが含まれます。
目的は大量の本番Dataを抽出することではありません。
通常はControlled Test RecordでConfidentiality Failureを十分に証明できます。
Tool PermissionとAction Validationをテストする
製品にAI ToolやAgentがあるなら、State-Changing Capabilityをすべてマッピングします。
その上で、モデルがUser Authorityを超えるOperationを要求した場合に何が起こるかを意図的にテストします。
最も強いSecurity Outcomeは、
「モデルが拒否した」
だけではありません。
本当に強い結果は、
「モデルが実行を試みてもBackendが拒否した」
です。
これによって、Applicationに独立したControl Layerが存在することを証明できます。
High-Impact Actionをテストする
Payment。
Security Setting。
Permission。
External Communication。
Infrastructure。
Destructive Data Change。
こうした操作には追加のAttentionが必要です。
AgentがAutonomousに実行できるか。
BackendがCurrent Userを確認するか。
Confirmationが必要か。
ConfirmationがExact TargetへBindされているか。
ActionをReplayできるか。
Low-Privilege UserがUnderlying Endpointへ直接到達できるか。
これはAI Workflowを通じて表現された、従来型High-Risk Business Logic問題です。
External Integrationをテストする
Integrationを一つ追加するたびにTrust Graphは広がります。
AI AgentがCRM、Messaging Platform、Payment System、Repositoryへ接続する可能性があります。
Assessmentでは、どのInformationがSaaS Platform外へ出るか、その見返りとしてExternal IntegrationがどのPermissionを与えるかを確認します。
Tool単体では安全でも、複数Toolの組み合わせによって新しいAttack Pathが作られる場合があります。
Internal Data Retrieval ToolとExternal Messaging Capabilityを組み合わせれば、Data Disclosure Channelになる可能性があります。
そのためSecurity Assessmentでは、Integrationを個別に見るだけではなく、Chainとしてテストする必要があります。
Rate LimitとResource Abuseを安全にテストする
AI Workloadは大きなCostを生む可能性があります。
そのためPre-Launch Testingでは合理的なAbuse Controlがあるか確認します。
実際にDenial of Serviceを起こす必要はありません。
Architecture上のLimitが存在するかを確認できます。
一つのAccountが事実上無制限のConcurrent Model Requestを作れないか。
一つのWorkflowが永遠に続かないか。
Large Document Uploadが不均衡なProcessing Costを生まないか。
Agentが高価なToolを繰り返し呼べないか。
目標は、実用的なConsumption Boundaryが存在することを確認することです。
Error Handlingをテストする
AI Infrastructureは複数の複雑なServiceを接続するため、Failure時に非常に詳細なDiagnosticを返すことがあります。
一つのIntegrationが失敗しただけで、UserへCredential、Internal Infrastructure Detail、Private Model Context、その他不要なDebug Dataを返してはいけません。
Error HandlingはTroubleshootingに必要な情報を提供しつつ、Information Disclosure Featureにならないようにする必要があります。
Fallback Pathをテストする
SaaS PlatformにはAlternate Execution Pathが存在する場合があります。
Primary Modelが失敗し、別Providerへ切り替える。
Retrieval Serviceが利用できず、Raw Database SearchへFallbackする。
Agent Toolが失敗し、Generic Internal APIを利用する。
SecurityはFallbackでも維持されなければなりません。
強く保護されたPrimary Pathがあっても、Broadly Privileged Emergency Pathが存在すれば意味がありません。
Pre-Launch TestingではDependency Failure時の挙動も意図的に確認する必要があります。
複数RoleでAI機能をテストする
Admin Account一つだけではSecurity Testingとして不十分です。
Applicationの本当のPermission Modelを表す複数IdentityでAI Featureを確認します。
必要ならAnonymous User。
Ordinary User。
High-Privilege User。
複数Tenant。
Restricted User。
Long-Running Workflow中にAccessがRevokedされたUser。
これによって、AI LayerがPermission Differenceを維持しているか、それともRoleをFlattenしているかを確認できます。
Model Failure後のApplicationをテストする
ローンチ前に最も価値のあるExerciseの一つは、
「モデルが間違った判断をする」
と意図的に仮定することです。
珍しい理論上のFailureではありません。
通常のArchitecture Testとして扱います。
モデルが間違ったToolを選択した。
何が起こるか。
別TenantのObjectを要求した。
何が起こるか。
External ContentがAgentへ予期しない宛先へ情報を送るよう促した。
何が起こるか。
モデルがUnsafe Parameterを生成した。
何が起こるか。
答えが毎回、
「モデルはそんなことをしないはず」
に依存しているなら、Security Boundaryを強化する必要があります。
Deterministic SystemがUnsafe Operationを拒否するなら、Architectureははるかに堅牢です。
Pre-Launch AI Security AssessmentではAttack Path全体を見る
個別のWeaknessを組み合わせると、Security Testingの価値が上がります。
Support DocumentにAttacker-Controlled Instructionがある。
RAGがそのDocumentを取得する。
モデルがInstructionへ従う。
AgentがCustomer Informationを要求する。
Global Service Credentialが別Tenant Recordを返す。
Messaging ToolがそのRecordを外部へ送る。
個別Componentだけを確認していると、この深刻度を見落とす可能性があります。
本当のVulnerabilityはChain全体に存在します。
そのためAI / LLM Security Testingでは、モデルが何個のPromptを拒否したかではなく、Complete Attacker Pathを評価するべきです。
Pre-Launch TestingはPost-Incident Testingより価値が高い
Security Flawは、CustomerがArchitectureへ依存する前の方が修正しやすいことが多くあります。
ローンチ前にTenant Authorizationが間違っていればRetrieval Boundaryを再設計できます。
Agent Service Identityが広すぎれば、Integrationが増える前にPermissionを変更できます。
Tool Architectureが過剰なAuthorityを与えていれば、Workflowが依存する前にCapabilityを分割できます。
製品が広く使われた後では、同じ変更のOperational Costが大きくなります。
AI SaaSでは、Pre-Release Adversarial Testingが特に価値を持ちます。
Security Crash TestはReal Business Riskを検証する
有用なSecurity Crash Testは、すべての奇妙なModel Responseを列挙するものではありません。
Attackerが意味のあるApplication Boundaryを越えられるかを確認するべきです。
Userが別Tenantになれるか。
Confidential Dataへアクセスできるか。
Agent ToolがUser Permissionを超えて動作できるか。
Malicious Retrieved ContentがUnauthorized Actionを発生させられるか。
APIをAbuseできるか。
一つのAccountがUncontrolled Resource Consumptionを起こせるか。
AIを経由して既存Business Ruleを回避できるか。
Engineering TeamやLeadership Teamが実際にActionを取れるのは、こうしたFindingです。
RemediationではPrompt一つではなくArchitectureを修正する
AI Vulnerabilityは表面的なRemediationが行われやすい分野です。
Security TeamがPrompt Injectionを実証する。
DeveloperがSystem Promptに一文追加する。
元のTestだけは失敗するようになる。
しかし同じPrivileged Toolは残っている。
Root Problemは消えていません。
より強いRemediationはSecurity Boundaryそのものを変えます。
Unauthorized RAG Contentが取得されたならRetrieval Authorizationを直す。
Agent Permissionが広すぎたならPermissionを減らす。
External ContentがSensitive ActionをTriggerできたならIndependent ApprovalまたはAuthorizationを追加する。
ModelへPrivate Dataを渡しすぎていたならContextを減らす。
Tool Outputを誤ってTrusted扱いしていたならValidation Pathを直す。
Prompt ChangeはDefense in Depthとして残しても構いません。
しかしArchitecture Controlの代わりにしてはいけません。
RetestingではUnderlying Security Propertyを確認する
Remediation後は、元のTest StringだけではなくAttack Objectiveを再度確認します。
Cross-Tenant Retrievalなら複数QueryでTenant Isolationを確認する。
Excessive Agent PrivilegeならRestricted Operationへの別経路を確認する。
Indirect Prompt Injectionなら、操作されたExternal Contentが依然として禁止されたSecurity Outcomeを発生させられないか確認する。
強いFixはVariationに耐えます。
弱いFixは、一つのKnown Demonstrationだけに耐えます。
ローンチはAI Securityの終わりではない
AI Productは継続的に変化します。
Modelが変わる。
System Promptが変わる。
Toolが追加される。
New Data Sourceが接続される。
Agent Autonomyが広がる。
新しいTenantとPermission Structureが増える。
初回ローンチ時に安全だったSaaS Platformでも、Traditional Vulnerabilityが追加されなくても新しいAttack Surfaceが生まれる可能性があります。
そのためAI SecurityはProduction Deployment後も継続する必要があります。
New Tool追加時はSecurity Reviewを行う
Toolを追加することは、単なるProduct Feature追加ではありません。
AIが何を引き起こせるかを変えることです。
Email Capabilityを持つChatbotには新しいExternal Communication Boundaryができます。
Account Modification Capabilityを持てばWrite Boundaryができます。
Administrative API Accessを持つAgentにはPrivilege Boundaryができます。
重要なCapability ExpansionはThreat Model Updateを伴うべきです。
Underlying Modelがまったく同じでも、Application Security Riskは大幅に増える可能性があります。
New Data Source追加時もSecurity Reviewを行う
RAGやExternal Dataも同じです。
HR Documentを接続すればPublic Documentationとは違うConfidentiality Requirementが生まれます。
Customer Uploadを追加すればIndirect Prompt Injection Surfaceが生まれます。
複数Tenant Repositoryを接続すれば新しいIsolation Requirementができます。
Web Browsingを追加すればUncontrolled External Contentが入ります。
Security Reviewは、モデル変更だけではなくInformation Authorityの変更に追従する必要があります。
Autonomyが増えたらSecurity Reviewを行う
ActionをRecommendするAI Assistantと、そのActionを自動実行するAgentではRisk Profileが違います。
Product TeamはRecommendationがAutonomous Executionへ変わるStepを意図的にReviewする必要があります。
そこが、Model Errorが単なるInformation Problemではなく、System Stateを変更するProblemへ変わる地点です。
最も安全なAI SaaS Architectureは「モデルは失敗する」と仮定する
最も強力なPre-Launch Design Assumptionは単純です。
モデルは間違える可能性がある。
Userを誤解する。
Malicious Contentへ従う。
間違ったToolを選ぶ。
Unsafe Parameterを生成する。
Contextに存在する情報を公開する。
別Componentが誤解するOutputを生成する。
この前提を受け入れると、Architecture Designは明確になります。
AuthorizationはModel外部に置く。
Sensitive Dataを最小化する。
ToolはLeast Privilegeで動かす。
High-Impact Actionへ強いControlを設ける。
Tenant Identityを全Layerで維持する。
External ContentをUntrustedとして扱う。
AI-Generated ParameterをValidationする。
ActionをLoggingする。
Resource Usageを制限する。
System Securityが、Perfect Model Behaviorを必要としなくなります。
AI SaaS Securityは「新しいTrust Boundaryを持つApplication Security」
Generative AIは、本当に新しいAttack Surfaceを作ります。
Prompt Injectionは現実です。
Agent Manipulationも現実です。
RAG PoisoningとRetrieval Riskも現実です。
Autonomous Tool Useは新しい結果を生みます。
しかし強力なDefenseは、よく知られたSecurity Foundationの上に構築されます。
Authentication。
Authorization。
Least Privilege。
Data Minimization。
Tenant Isolation。
Input Validation。
Output Handling。
Monitoring。
Rate Limit。
Safe Failure。
Impactに応じたHuman Approval。
AIは強力なDeterministic Controlの中で動作するべきであり、それらを置き換えるべきではありません。
本番公開を控えるSaaS Platformに必要なのは、
「モデルが絶対に奇妙な挙動をしない」
ことを証明することではありません。
本当に重要なのは、
奇妙な挙動や操作されたモデル挙動が、密かにUnauthorized Application Behaviorへ変化しないことを証明することです。
それがProduction前に確認すべきSecurity Standardです。
SaaSプラットフォームのAIセキュリティに関するよくある質問
AI SaaS Securityとは何ですか？
LLM、RAG、AI Agent、Model API、自律型Toolを利用するSaaS Applicationを保護するためのSecurity Practiceです。Authentication、Authorization、Tenant Isolationなど従来型SaaS Securityと、Prompt Injection、Sensitive Information Disclosure、Excessive AgencyなどAI固有リスクを組み合わせます。
SaaS企業はAI機能公開前に何をテストすべきですか？
Authentication、Authorization、Tenant Isolation、RAG Retrieval、Prompt Injection、Sensitive Data Exposure、Tool Permission、API、Model Output Handling、Agent Action、Resource Consumption、Logging、操作されたAI挙動によるDownstream Impactを評価すべきです。
AI SaaSでTenant Isolationが重要なのはなぜですか？
AIはShared Database、Vector Store、Cache、Memoryから情報を取得できます。Tenant Authorizationが弱いと、一つのCustomerの情報が別CustomerのModel Contextへ入る可能性があります。
System Promptで機密SaaS Dataを保護できますか？
System PromptはModel BehaviorをGuidanceできますがAccess Controlの代わりにはなりません。Sensitive InformationはModel Contextへ入る前に制限し、重要なAuthorizationはDeterministic Application Controlで強制するべきです。
SaaS PlatformにおけるPrompt Injectionはどの程度危険ですか？
深刻度はモデルが何へアクセスし、何を実行できるかによって大きく変わります。Text-Only ChatbotであればIncorrect Outputにとどまる可能性がありますが、Private DataやPrivileged ToolへアクセスできるAgentでは大きなImpactにつながります。
AI AgentはAdministrator Credentialを使用すべきですか？
そのAuthorityが本当に必要で、かつ独立したControlがある場合に限るべきです。Broad Service CredentialはLow-Privilege Userへ通常利用できないCapabilityへの間接アクセスを与える可能性があります。
AI ToolにはHuman Approvalが必要ですか？
High-Impact ActionではHuman Approvalが有用です。ただしApprovalはAuthorizationを置き換えるのではなく補完するべきです。Low-Risk Operationは自動化し、Destructive、Financial、Security-Sensitive Operationには強いControlを適用できます。
Multi-Tenant SaaSでRAGは安全に使えますか？
はい。ただしUnauthorized DocumentがModel Contextへ入る前にTenant Authorizationを強制する必要があります。Semantic RelevanceによってPermissionを決めてはいけません。
AI Security Testingは通常のPenetration Testingを置き換えますか？
いいえ。AI SaaSも通常のWeb Application、API、Authentication、Business Logicに依存しています。AI固有Security Testingは、Web Application Penetration TestingやAPI Security Testingを補完すべきです。
SaaS企業はいつAI Security Testingを行うべきですか？
Production Launch前に加え、Agent Permission、Data Source、Tool、Model Architecture、Autonomous Capabilityを大きく変更した後にも実施する価値があります。
最も重要なPre-Launch AI Security原則は何ですか？
モデルが間違った判断をする可能性を前提に設計することです。 Model Behaviorが操作されたとしても、Authentication、Tenant Isolation、Data Access、Sensitive Tool OperationはDeterministic Controlによって保護されていなければなりません。
