AIアプリケーションは、その有用性を支えるほぼすべての機能でAPIへの依存を強めています。モデル自体がAPIエンドポイント経由で利用されることもあれば、Retrievalが別サービスを呼び出し、AI AgentがAPIを利用してビジネスデータの読み取り、レコード作成、メッセージ送信、ワークフロー開始などを行うこともあります。AuthenticationはIdentity Providerが担当し、Billing、Storage、Monitoringは別のサービスで処理される場合もあります。
そのため、AI API Securityは現代のAIセキュリティにおける基盤の一つになっています。
リスクは、盗まれたAPI Keyや公開されたModel Endpointだけではありません。AIアプリケーションが正しくAuthenticationされていても、あるUserが別UserのObjectへアクセスできる可能性があります。Model自体は安全にHostingされていても、Overprivileged Tool APIによって破壊的なActionが可能になる場合があります。
Downstream Serviceが、Requestを開始したUserではなくShared AI Service Accountだけを信頼している場合もあります。また攻撃者はPrivileged Accessを取得しなくても、高コストなInference Endpointを大量に利用し、サービスへ経済的な負荷を与える可能性があります。
こうした問題はTraditional API Securityと大きく重なります。OWASP API Security Top 10では、Broken Object Level Authorization、Broken Authentication、Broken Object Property Level Authorization、Unrestricted Resource Consumption、Broken Function Level Authorizationなどが依然として重要なAPIリスクとして扱われています。
AIでは、さらに新しいLayerが追加されます。
どのAPIを、どのParameterで、どの順序で呼び出すかをModel Reasoningが決定できるようになるからです。
そのため安全なArchitectureでは、ModelをDeterministic API Boundary内で動作する高度なRequest Generatorとして扱う必要があります。
ModelはActionを選択できます。
しかし、そのActionがAuthorizedかどうかを決定するのはAPIです。
AI APIには従来型API Security以上の対策が必要な理由
通常のAPIでは、Clientから比較的明確なRequestが送信されます。
一方、AI対応システムではUserとAPIの間に追加のDecision-Making Layerが入ります。
たとえばUserが、
「この顧客のアカウント問題を修正して」
と依頼したとします。
ModelはRequestを解釈します。
対象Customerを特定します。
適切だと思うToolを選択します。
Parameterを生成します。
ApplicationがAPI Requestを送信します。
別BackendがAccountを変更します。
Userから見ると一つのConversation Actionにしか見えません。
しかしSecurityの観点では、複数のTrust Boundaryが横断されています。
OWASPがExcessive Agencyとして説明している問題もここに関係します。LLM Applicationに過剰なFunctionality、Permission、Autonomyが与えられると、Model ErrorやManipulationが実際の破壊的Actionへ変わる可能性があります。
API Layerは特に重要です。
多くのAIアプリケーションでは、Model Reasoningと実際のApplication Stateの間に存在する最後のDeterministic Boundaryだからです。
このBoundaryが強ければ、Manipulated AI BehaviorもContainできます。
逆にBackendが「AI Applicationから来たRequestだからTrusted」と判断すれば、Prompt InjectionやModel ErrorがUnauthorized Actionへの経路になります。
AI APIのAttack Surfaceをマッピングする
AI API Architectureを保護する最初のステップは、実際に何が存在しているのかを把握することです。
多くのTeamは「AI API」という言葉から、PromptをModelへ送信する一つのEndpointだけを想像します。
Production Applicationでは、Attack Surfaceは通常それよりはるかに大きくなります。
Public Model Endpoint。
Internal Orchestration API。
RAG Service。
Tool API。
Authentication Service。
Usage / Billing API。
Vector Database。
Logging System。
MCP Server。
Third-Party API。
Agent-to-Agent Service。
Security Teamは、元のUser Requestから最終Downstream ActionまでのPathを追跡する必要があります。
誰がAuthenticationされるのか。
どのServiceがPromptを受け取るのか。
どのServiceがModelを選ぶのか。
どのIdentityがToolを呼び出すのか。
どのBackendがAuthorizationを確認するのか。
どのData Storeへ到達できるのか。
Secretはどこに保存されているのか。
LimitはどこでEnforceされるのか。
このArchitecture Mapは重要です。
安全なModel Endpointが、安全でないApplicationの中に存在することは十分にあり得るからです。
Model API Endpointを保護する
Model Endpointは、高コストなCompute ResourceやSensitive Application Behaviorへの入口になり得るため、高価値なInterfaceです。
最初のControlはAuthenticationです。
Non-Public Endpointには、意図されたClientだけがアクセスできるべきです。
Authentication MechanismはCredential Leakage、Weak Token Handling、Broken Session Designといった通常のAPI Security Weaknessにも耐えなければなりません。
しかしAuthenticationだけでは不十分です。
Endpointは、Authenticated Identityごとに何が許可されているかも強制する必要があります。
Valid User Tokenを持っているからといって、すべてのModel、すべてのSystem Instruction、すべてのTenant、すべてのTool-Enabled Workflowへアクセスできてはいけません。
Authenticationが答える質問は、
「誰が呼び出しているのか？」
です。
Authorizationが答える質問は、
「そのCallerは何へアクセスしてよいのか？」
です。
AI Endpointには両方が必要です。
API KeyをPrivileged Credentialとして扱う
API KeyはService間で利用しやすいため、AI Infrastructureでも広く使われています。
しかし実際にはOverprivilegedになっていることが少なくありません。
一つのModel Keyで複数Environmentへアクセスできる。
一つのService TokenがDevelopmentとProductionの両方で使われる。
Inferenceだけに必要なKeyがClient-Side Codeへ埋め込まれている。
別のKeyがApplication LogやConfiguration Repositoryに残る。
Security Principleは従来と同じです。
CredentialはPurposeに応じてScopeを限定し、User-Controlled ContextやModel-Visible Contextの外部で保管する必要があります。
通常、AI ModelがBackendから別APIを呼び出すためのSecretそのものを見る必要はありません。
ApplicationにはCredentialが必要です。
ModelにはCapabilityが必要です。
この二つは同じではありません。
特にAgentic Systemでは、この分離が重要です。
Model Context内に存在するSecretは、Model BehaviorやApplication Loggingを通じて将来的にExposureする可能性がある情報の一部になるからです。
API SecretをPromptに入れない
System Promptは、Internal InstructionやIntegration Detailを保存する便利な場所として扱われることがあります。
しかしSecret Storeにしてはいけません。
API Key、Bearer Token、CredentialなどをModel Contextに含めると、Prompt InjectionやInformation Disclosureの問題から露出する可能性があります。
より強いArchitectureでは、CredentialをBackend Infrastructure内に保持します。
Modelは、
「UserのInvoiceを取得して」
とOperationをRequestするだけです。
BackendがAuthorizationを確認し、保護されたCredentialを使ってOperationを実行します。
ModelがRaw API Keyを見る必要はありません。
API Keyを通常のSecurity CredentialとしてRotation・Revocationする
AI API Keyも通常のCredential Lifecycle Managementに対応する必要があります。
Exposureが疑われる場合はRotationできる。
Compromised IntegrationをAI Platform全体の再構築なしにRevocationできる。
異なるEnvironmentが不要に同じCredentialへ依存しない。
Audit SystemでSensitive Keyがどこで使われているか把握できる。
これらはAI固有のSecurity Practiceではありません。
AIによってCredential Sprawlが発生し得るServiceやIntegrationの数が増えているだけです。
Broken Object Level AuthorizationはAI APIでもCritical
AI Application Designで危険な誤解の一つは、
「UserがNatural Language経由でDataへアクセスするなら、Traditional Object Authorizationの重要性は下がる」
と考えることです。
実際は逆です。
OWASPではBroken Object Level AuthorizationがAPI1:2023として扱われています。APIはObjectを表すIdentifierで動作するEndpointを多数持ち、Externally Supplied Identifierを利用してObjectへアクセスするFunctionには適切なObject-Level Authorizationが必要です。
AIは単に、そのIdentifierをUserの代わりに生成できます。
たとえばCustomer Invoiceを取得できるAssistantがあるとします。
Userが、
「Invoice 84172を見せて」
と依頼します。
ModelがそのIDを使ってAPIを呼び出します。
Backendは、
「AIがこのIdentifierを生成したからAuthorizedだろう」
と判断してはいけません。
Authenticated Userが本当にそのInvoiceへアクセスできるかを確認する必要があります。
同じ原則はDocument、Account、Ticket、Project、Transaction、Tenant Resourceにも当てはまります。
User-to-Model Authorization
最初のAuthorization Boundaryは、UserがAI Applicationを通して何へアクセスできるかを決定します。
Userは一つのOrganizationへ所属しているかもしれません。
別UserはAdministratorかもしれません。
別UserはRead-Only Permissionだけを持つかもしれません。
これらのPermissionは、利用可能なFeature、Model、Data Source、Toolへ反映されるべきです。
ただし、このLayerだけでは十分ではありません。
AI Application自体も間違える可能性があるからです。
Model-to-Tool Authorization
第二のBoundaryは、ModelがTool Layerに実際に何を実行させられるかを決めます。
Backendが、
「AI LayerですでにUserを確認したはず」
と仮定すると、Agentic Systemは危険になります。
Low-Privilege UserのConversationが、Highly Privileged Service Identityで動くToolをTriggerする場合があります。
Tool側でAuthorizationを再度Enforceしなければ、AIがPrivilege Bridgeになります。
そのため最も安全なArchitectureでは、AuthorizationをWorkflow全体で維持します。
Broken Function Level AuthorizationはAI Toolでも重要
Object Authorizationは、
「Userが特定Objectへアクセスできるか」
を確認します。
Function-Level Authorizationは、
「Userがそもそもその種類のOperationを実行できるか」
を確認します。
AIではNatural Language InterfaceによってUnderlying OperationがUserから見えにくくなるため、このControlがさらに重要になります。
Userの画面に、
「Admin: Disable Account」
というButtonが表示されていないかもしれません。
しかしAgent内部にはAccountをDisableできるToolが存在する可能性があります。
Ordinary UserがConversationを通じてそのToolを実行できるなら、Traditional Admin UIへ一度もアクセスしていなくてもFunction-Level Authorizationは失敗しています。
APIはRequestの背後にあるRoleを理解する必要があります。
ModelのDecisionだけでは不十分です。
Broken Object Property AuthorizationによるAI Data Leakage
より微妙なAPI Weaknessとして、正規Object内部の個別PropertyへのAccessがあります。
Authenticated UserはObjectそのものにはアクセスできても、すべてのFieldを受け取るPermissionがあるとは限りません。
たとえばCustomer Support AgentがCustomer Profileを取得すること自体は正当かもしれません。
しかし完全なRecordが必要でしょうか。
BackendがInternal Risk Flag、Private Note、Authentication Metadata、その他AI Featureには不要なFieldまで返している可能性があります。
Complete ObjectがModel Contextへ入る時点で、ApplicationはExposure Surfaceを広げています。
強いDesignでは、API BoundaryでData Minimizationを行います。
Workflowが必要とするFieldだけを返します。
不要なSensitive InformationをModelへ渡し、
「公開しないで」
というInstructionだけに依存してはいけません。
Modelが見る前にDataを最小化する
AI ApplicationはImplementationを簡単にするためOver-Fetchしがちです。
ToolがDatabase Object全体を取得する。
Modelが必要な部分を判断する。
便利ではありますが、Confidentialityの観点では弱いDesignです。
より強いArchitectureではData LayerでFilterします。
AIがInvoice StatusとDue Dateだけ必要なら、CustomerのFull Billing Profileは不要です。
Support AssistantがCurrent Subscription Tierだけ必要なら、Internal Fraud Metadataは不要かもしれません。
RAG Queryが一つのAuthorized Documentだけ必要なら、無関係DocumentをContextへ入れるべきではありません。
これによってPrompt Injection、Logging Error、Unintended Model DisclosureのImpactを小さくできます。
Model EndpointにはResource Controlが必要
AI Endpointは運用Costが高くなる可能性があります。
Long Input。
Repeated Agent Loop。
高価なModel。
Large Token Output。
こうしたFeatureはInference Computeを大量に消費できます。
OWASPではUnbounded ConsumptionがLLM10:2025として扱われ、Uncontrolled InferenceはService Degradation、Denial of Service、Financial Lossを引き起こす可能性があるとされています。
つまりAI API SecurityにはEconomic Securityの側面もあります。
攻撃者は必ずしもDataを盗む必要がありません。
Applicationに大量のCostを発生させるだけでもImpactを作れます。
そのためRate Limit、Quota、Workload ControlはInfrastructure Controlであると同時にSecurity Controlです。
Rate LimitをUserとWorkload Riskに合わせる
Global Flat Rate Limitでも、ないよりは安全です。
しかし成熟したAI Platformではさらに細かく設計できます。
User Role。
Model Cost。
Endpoint Type。
Tool Capability。
Tenant。
Workflow。
Read-Only Lightweight Inference Endpointと、Toolを持つAutonomous AgentではRisk Profileが異なります。
Resource Limitは実際のPotential Impactに対応するべきです。
これはCompromised AccountのContainmentにも役立ちます。
AuthenticationされたValid Accountだからといって、無制限に高価なActivityを生成できてはいけません。
Token LengthとContext LengthもAbuse Surfaceになる
AI EndpointはLarge Prompt、File Input、Retrieved Contextを受け付けることがあります。
便利なFeatureです。
同時にInference Costを大幅に増やすこともできます。
ApplicationはUserがRequest Complexityへどの程度影響できるかを把握する必要があります。
何個のFileを追加できるか。
最大Sizeはどれくらいか。
Retrieval Resultはいくつ入るか。
Agentはどれくらい長く継続できるか。
一つのRequestから何回Tool Callが発生できるか。
Maximum Response Sizeはどれくらいか。
Unbounded WorkflowはFinancial RiskとAvailability Riskの両方を生みます。
一つのAPI Requestが、制御されていない高コストOperation Chainを静かに開始できてはいけません。
Agent LoopにはBudget Boundaryが必要
Agentic AIでは、一つのUser Requestが多数のDownstream Actionへ変換されます。
Userが一つのGoalを送る。
AgentがReasoningする。
Toolを呼ぶ。
Resultを処理する。
別Toolを呼ぶ。
Retryする。
Replanする。
API Layerから見ると一つのUser Workflowでも、内部では数十回の高Cost Operationが動いている可能性があります。
そのためSecurity Architectureでは、Initial HTTP Request数だけではなく、一回のAgent Run全体にCapability Budgetを設けるべきです。
これはAIがTraditional API Assumptionを変えるもう一つの例です。
Tool APIはModel以上に制限する
AI Tool APIはPrivate Network内に置かれていることが多く、それがFalse Confidenceにつながります。
Backend APIがInternetへ直接Exposureしていない。
AI Orchestration Serviceだけが呼び出せる。
だからUser-Level Authorizationは不要だろう。
この考え方は危険です。
AI Orchestration LayerはAttacker-Controlled Requestを処理しています。
Prompt Injectionの影響を受ける可能性があります。
Malicious Authenticated Userが操作できます。
Retrieved External ContentがAgent Reasoningへ影響する可能性もあります。
そのためAI-Generated Actionを受け取るInternal Tool APIは、Trusted Internal FunctionではなくSecurity-Sensitive APIとして設計するべきです。
Internal APIにもAuthorizationが必要
「Internal」という言葉はNetwork Placementを示しているだけです。
Trustを証明するものではありません。
ModelがInternal APIへ到達できるなら、Modelへ影響できるものは間接的にそのAPIへ影響できます。
APIはRequestに関連するIdentityとPermissionを検証する必要があります。
User-Scoped Authorization。
Agent Identity。
Service Authorization。
Object-Level Controls。
あるいはそれらのCombination。
正しいModelはArchitectureによって異なります。
しかしSensitive Operationを実行するInternal APIにUnrestricted Internal Trustを与えるべきではありません。
Connected ServiceがBlast Radiusを広げる
AI Applicationは多数の独立Serviceを接続します。
Email。
CRM。
Cloud Infrastructure。
Repository。
Payment。
Support System。
Database。
Integrationが増えるたびにPotential Blast Radiusも広がります。
ModelがManipulatedされたら、どのServiceへ到達できるのか。
一つのIntegrationがCompromisedされたら、どのDataをModelへ返せるのか。
一つのTool Outputが次のTool Callへ影響できるか。
AI API Attack SurfaceはCompositionalです。
安全なRead APIと安全なMessaging APIでも、
一方からConfidential Informationを読み、
もう一方から外部へ送信できるなら、
組み合わせとして危険になる可能性があります。
Tool Chainingを明示的にThreat Modelする
APIを一つずつReviewするだけでは、こうしたCombinationを見落とす可能性があります。
Security TeamはPotential ChainをMapする必要があります。
Customer Dataを取得 → Email送信。
Repositoryを読む → External Serviceを呼ぶ。
Internal Documentを検索 → Public Postを作る。
Cloud Configurationを読む → Infrastructureを変更する。
Vulnerabilityは個別Endpointには存在しないかもしれません。
それらを接続したAuthority Graphに存在します。
これはAI API SecurityをAI Agent SecurityやAI Tool Securityへ直接接続する考え方です。
MCPは新しいAPI Authorization Layerになる
Model Context Protocolは、AI ApplicationへToolやResourceを公開する方法として利用が広がっています。
MCP ServerによってModelがExternal SystemへQueryしたりAPIをCallしたりできるため、MCPも重要なAuthorization Boundaryになります。
Protected MCP ServiceではResource-Specific Accessが重要です。
AuthorizationではTarget Resourceを明示し、Tokenを本来アクセスすべきServiceへBindする考え方が使われます。
Security Principleは通常のAPI Designと同じです。
ある場所でValidなTokenが、すべての場所でValidになってはいけません。
Token Audience ValidationでCross-Service Trust Confusionを防ぐ
Complex AI Architectureでは、多数のOAuth-Protected Serviceが利用されます。
TokenがIntended ResourceへBoundされていなければ、一つのService向けにIssuedされたCredentialが別Serviceで誤ってAcceptされる可能性があります。
この考え方はMCPだけに限りません。
AI Systemはますます多数のAPIを横断します。
TokenはIntended AudienceへScopeされるべきです。
Broadly Transferable Credentialは不要なCross-Service Riskを生みます。
Service IdentityもUser Identityと同じように精査する
AI APIではMachine-to-Machine Accessが多く利用されます。
一つのServiceが人間の直接操作なしに別ServiceをCallする。
このService Identityは非常に強いAuthorityを持つ可能性があります。
重要なのは、
「AI ServiceがAuthenticatedされているか」
だけではありません。
Identityが必要最小限のAuthorityしか持っていないか
です。
Model Orchestration Serviceが全Customer Database Operationへ無制限Accessする必要は通常ありません。
Retrieval WorkerがProduction Administratorになる必要もありません。
Machine IdentityだからといってBroad Privilegeを持たせる理由にはなりません。
AI API LogにはIdentity Contextが必要
AI-Generated RequestがBackend LogでGeneric Service Accountとしてしか記録されない場合、Incident Responseは難しくなります。
Security Teamは重要Actionを再構築できる情報を必要とします。
どのUserがWorkflowを開始したか。
どのAgentがActionしたか。
どのAPI Endpointが実行されたか。
どのTool / Functionが選択されたか。
どのAuthorization Decisionが適用されたか。
どのObjectが変更されたか。
一つのConversation Instructionが複数Downstream API ActionへつながるAgentic Systemでは、このTraceabilityが特に重要です。
Loggingする内容に注意する
Detailed LoggingはSecurityを改善します。
同時に、新しいSensitive Data Storeを作る可能性があります。
Prompt BodyにはConfidential Informationが入るかもしれません。
Model ResponseにはPersonal Dataが含まれるかもしれません。
Tool ParameterにはObject IdentifierやBusiness-Sensitive Valueが含まれる可能性があります。
Authentication TokenをOrdinary LogへCopyしてはいけません。
AI API ObservabilityにもData Minimizationが必要です。
調査に必要な情報はLogする。
しかしSystemを通過したすべてのSecretを保存するShadow Archiveを作ってはいけません。
AI API SecurityではPrompt Injectionも考慮する
Prompt Injection自体は技術的にはAPI Vulnerabilityではありません。
しかしAPI DesignによってPrompt Injectionが意味のあるExploitになるかどうかが決まります。
攻撃者がModelをManipulateし、Administrative ActionをRequestさせたとします。
APIがUser Roleを独立して確認すれば、そのRequestは拒否されます。
一方BackendがAI Serviceから来るすべてのRequestをTrustedと判断すれば、同じModel ManipulationがPrivilege Escalationになります。
そのためPrompt Injection Testingでは、Model Behaviorだけで止めず、必ずAPI Layerまで追跡する必要があります。
Prompt Injectionが成功してもAuthorizationで止まるべき
これはAI Applicationの非常に優れたDesign Testです。
Prompt Injectionが成功したと仮定します。
何が起こるでしょうか。
Modelが別TenantのDataをRequestする。
APIが拒否する。
ModelがHigh-Impact FunctionをRequestする。
Function-Level Authorizationが拒否する。
ModelがInformationを外部へ送ろうとする。
PolicyがDestinationをBlockする。
ModelがState-Changing ActionをRequestする。
Human Approvalが要求される。
LLMが唯一のControlではないため、Systemは安全を維持できます。
これがDefense in Depthです。
AI API SecurityとSSRF
AI SystemはURLを頻繁に処理します。
UserがAgentへWeb PageのSummaryを依頼する。
ToolがRemote ResourceをFetchする。
Model-Generated ParameterがOutbound Requestになる。
Application-Controlled InfrastructureがAttacker-Influenced DestinationへRequestする場合、Server-Side Request ForgeryのRiskが生まれます。
SSRF PreventionをAI LayerのProbabilistic Behaviorへ依存させてはいけません。
URL Validation。
Network Restriction。
Destination Policy。
これらはDeterministic Backend Controlで行うべきです。
Internal NetworkやCloud Environmentへ接続されたAgentでは特に重要です。
通常External UserからReachできないResourceがServer-Side Request経由でReachableになる可能性があるからです。
External URLをSecurity-Sensitive Parameterとして扱う
Modelが生成したURLだからといってTrustedにはなりません。
Userが直接入力した場合と同じValidationが必要です。
DestinationがInternal AddressへResolveしないか。
RedirectでFinal Destinationが変わらないか。
ToolにUnrestricted Internet Accessが本当に必要か。
Metadata InterfaceやManagement Interfaceへ到達できないか。
Security-Sensitive Toolは、実際のWorkflowに必要なDestinationだけへAccessできるよう制限するべきです。
AI-Generated API Parameterには完全なValidationが必要
Structured Function CallingはDeveloperへFalse Sense of Safetyを与えることがあります。
ModelがJSONを生成する。
Schema ValidationがPassする。
ApplicationがExecuteする。
しかしValid Schemaが証明するのはStructureだけです。
PermissionやBusiness Correctnessを証明するものではありません。
Account IdentifierがFormat上ValidでもUnauthorizedかもしれない。
URLがSyntactically CorrectでもUnsafeかもしれない。
QuantityがValid IntegerでもBusiness Policy外かもしれない。
FilenameがValid StringでもAllowed Location外を指しているかもしれない。
Schema Validationは有用です。
しかしSecurity ValidationにはContextが必要です。
Modelに任意のPrivileged API Requestを組み立てさせない
Generic Request ToolはAgentへ非常に高いFlexibilityを与えます。
たとえばLLMが任意のHTTP Method、URL、Header、Request Bodyを指定できるToolを考えます。
これは事実上、
Probabilistic Model Reasoningによって操作されるGeneral-Purpose API Client
です。
Low-Risk Isolated Environmentでは広いToolが許容される場合もあります。
しかしPrivileged Production EnvironmentではNarrow Functionの方が安全です。
call_any_internal_api
のようなFunctionより、
get_current_customer_orders
create_support_draft
update_authorized_ticket
のようにReal Business Operationに対応したCapabilityの方がAuthorizationを明確にし、Attack Surfaceを縮小できます。
APIから返されるDataもUntrusted
AI API SecurityはOutbound Requestだけの問題ではありません。
API Responseも次のModel Reasoningへ影響します。
ToolがUser-Generated Support Ticketを取得する。
External ServiceがAttacker-Controlled Textを返す。
Search APIがMalicious Web Contentを返す。
ModelがそのResponseを処理し、次のActionを決定する。
これはIndirect Influence Pathを作ります。
最初のAPI CallはRead-Onlyかもしれません。
それでもResponseが後のHigh-Impact Tool Actionへ影響する可能性があります。
そのためExternal APIやUser-Controlled APIから取得したDataは、Retrieval後もUntrusted Classificationを維持する必要があります。
API Outputを自動的にAgent Instructionにしない
強いArchitectureでは、InformationとAuthorityを分離します。
CRM ResponseはRecord内容をModelへ伝えられます。
しかしAgentが何を実行してよいかまで自動的に決定してはいけません。
Web PageはResearch Informationを提供できます。
しかしSystem PolicyをOverrideしてはいけません。
Tool ResponseはErrorを報告できます。
しかし別Toolの利用Authorizationにはなりません。
Agent Workflowが複数Serviceを組み合わせるほど、この区別は重要になります。
Third-Party AI APIはSupply-Chain Riskを作る
多くのApplicationがThird-Party Model ProviderやAI Serviceへ依存しています。
これはExternal Trust Boundaryを作ります。
Organizationは各ProviderへどのInformationを送っているか把握する必要があります。
どのCredentialが使われているか。
Failureをどう処理するか。
どのDownstream FunctionalityがそのServiceへ依存しているか。
External APIのBehavior、Rate Limit、Authentication Requirementが変更されれば、Application Operationも変化する可能性があります。
Security DesignではDocumentされていないAssumptionへの不要なDependencyを避けるべきです。
合法で信頼できるThird-Party Serviceでも、Supply-Chain Risk自体は存在します。
Fallback ModelもSecurity Reviewする
一部のProductではPrimary ModelとFallback Providerを使います。
Reliabilityの観点では有用です。
Securityの観点ではFallback Pathにも同等のReviewが必要です。
同じDataを受け取るのか。
同じPrivacy Guaranteeを持つのか。
Tool Schemaを違う方法でInterpretしないか。
Authenticationは異なるか。
GuardrailはConsistentか。
Secure Primary PathがInsecure Fallback Pathを補うことはできません。
AI APIをPenetration Testする方法
AI API Penetration Testでは、Traditional API TestingとAI-Specific Attack Path Analysisを組み合わせる必要があります。
最初にEndpoint、Identity、ServiceをMapします。
どのEndpointがPublicか。
どれがInternalか。
どれがAuthenticationを必要とするか。
どれがState-Changing Operationを実行するか。
次にRole間のPermissionを比較します。
Normal UserがAdmin Functionalityを呼べるか。
一人のUserが別UserのObjectへアクセスできるか。
一つのTenantが別TenantのDataへ到達できるか。
Hidden Tool Endpointが、Intended Agent Workflow外から呼ばれてもAuthorizationをEnforceするか。
これはTraditional API Penetration TestingをAI Architectureへ適用したものです。
その次にModel Influenceを評価します。
Prompt ManipulationによってSensitive API OperationをRequestさせられるか。
Retrieved ContentがTool Selectionを変えられるか。
Model-Generated ParameterがObject BoundaryやNetwork Boundaryを越えられるか。
一つのTool Responseが別のHigh-Impact ActionをTriggerできるか。
Assessmentは最終的なApplication ImpactまでChainを追跡するべきです。
API KeyとTokenをテストする
Credential Handlingは独立してReviewする価値があります。
SecretがFrontend Codeに含まれていないか。
LogがTokenをExposureしていないか。
一つのKeyが無関係なEnvironment間でReuseされていないか。
CredentialのScopeは適切か。
Expired / Revoked TokenがCached Agent Session経由で動作し続けないか。
Protected ServiceがIntended Token AudienceをValidationしているか。
MCP-Connected ToolではResource-Specific Authorizationも重要になります。
Credentialは、本来IssuedされたAuthorityだけを証明するべきです。
Natural Language経由でObject Authorizationをテストする
Traditional API TestingではObject Identifierを手動で別IDへ置き換えます。
AI Interfaceは別のPathを作ります。
Natural Language RequestによってModelがUnauthorized Objectを取得できるか確認します。
重要なのは、Modelが別ObjectのIdentifierを知っているかではありません。
Request後にBackendがそのObjectを返すかどうかです。
User-Controlled Identifierを利用してDataへアクセスするOperationにはObject-Level Authorizationが必要というBOLAの原則は、AI Interfaceでも変わりません。
Toolの裏側にあるFunction-Level Authorizationをテストする
Tool VisibilityとPermissionを混同してはいけません。
Ordinary UserにはAdministrative Toolが表示されていないかもしれません。
しかしUnderlying APIがUnauthorized CallをRejectするか確認する必要があります。
最も強いControlはServer-Side Enforcementです。
Toolを隠すことだけがDefenseなら、Alternate PathからEndpointへ到達した瞬間にBoundaryが失敗する可能性があります。
Cross-Tenant Isolationをテストする
Multi-Tenant AI ApplicationではTenant Isolationを強くTestする必要があります。
Tenant IdentityをStack全体で追跡します。
Authentication。
Model Request。
RAG Retrieval。
Tool Call。
Internal API。
Database。
Cache。
Logs。
FrontendではTenant AのObjectしか表示されていなくても、Internal AI ToolがGlobal Accessで静かに動いているかもしれません。
Security Testingは、このDifferenceを見つける必要があります。
Resource Exhaustionをテストする
AI API AssessmentではResource Controlも確認します。
一人のUserが非常に高CostなPromptを大量に生成できるか。
大量のConcurrent InferenceをTriggerできるか。
Agent LoopがMeaningful Limitなしで継続できるか。
Repeated File ProcessingでCostを増幅できるか。
安価なRequestが大量のDownstream API Callを引き起こせるか。
Testingの目的はControlled Validationであり、Production Disruptionを起こすことではありません。
Tool Chainをテストする
Individual Endpoint Testingの次にComposition Testingを行います。
一つのAPIがInformationを読み、別APIが外部へ送信できるか。
Search Functionで見つけたObjectを別Functionが変更できるか。
User-Controlled API ResponseがAgentをPrivileged Operationへ誘導できるか。
一つのModel Outputが別ServiceのTrusted Instructionになれるか。
Traditional API VulnerabilityがAgentic Attack Pathになるのは、こうした組み合わせです。
Service-to-Service Trustをテストする
Internal Serviceが、
「Trusted Serviceから来たRequestだから」
という理由だけでAcceptしている箇所を特定します。
厳密に制御されたArchitectureでは合理的な場合もあります。
しかしTrusted ServiceがUserやAI Modelから直接Influenceを受ける場合は危険です。
「AI Backendしか呼べないからUser-Level Authorizationは不要」
というInternal APIは慎重にReviewするべきです。
AI Backend自体がUser-Controlled Decision Surfaceだからです。
Sensitive Contextを漏らさないError Handlingをテストする
AI APIはDeveloper SupportのためVerbose Errorを返す場合があります。
Production Errorで不要なSecret、Internal URL、Credential、System Prompt、Sensitive Stack InformationをExposureしてはいけません。
Model Orchestrationが複数External Serviceを利用する場合は特に重要です。
一つのIntegration FailureによってRequest UserへAuthentication MaterialやInternal Architectureが漏れてはいけません。
LoggingとAuditabilityをテストする
Confirmed Security EventはTraceableでなければなりません。
どのUserがWorkflowを開始したか。
どのModel / AgentがAPI ActionをRequestしたか。
どのCredentialが使われたか。
どのObjectが影響を受けたか。
どのToolがRequestを作ったか。
Sensitive ActionがGeneric Backend Service Callとしてしか見えない場合、Incident Responseは不必要に難しくなります。
Secure AI API Architectureを構築する
強いAI API Securityに、まったく新しいCybersecurity Principleが必要なわけではありません。
UserとBackendの間にModelが存在しても、既存Principleを一貫して適用することが必要です。
Meaningful ActorをAuthenticationする。
Workflow全体でIdentityを維持する。
ObjectをAuthorizeする。
FunctionをAuthorizeする。
Service CredentialをNarrow Scopeにする。
Modelへ到達する前にDataをMinimizeする。
高Cost ResourceをLimitする。
AI-Generated ParameterをUntrustedとして扱う。
External API ResponseもUntrustedとして扱う。
Model ReasoningとPermission Enforcementを分離する。
Sensitive ActionをAuditableにする。
そして最も重要なのは、
Modelが間違った判断をする可能性を前提にBackendを設計することです。
その前提でもArchitectureが安全なら、Securityははるかに強くなります。
AI LayerがPermission Upgradeを作ってはいけない
有用なDesign Testは、通常UIからUserが持つAuthorityとAI Interface経由のAuthorityを比較することです。
通常Applicationで別TenantのRecordを取得できないなら、Agentへ質問しても取得できてはいけません。
Admin Actionを直接実行できないなら、AI Interface経由で間接的に実行できてもいけません。
Protected Internal APIへAccessできないなら、Model ReasoningがShortcutを作ってはいけません。
AIはWorkflowを簡単にできます。
Permissionを静かに拡大してはいけません。
Modelが不完全でもStrong API SecurityならAIは安全になる
Model Securityは今後改善します。
Prompt Injection Defenseも改善します。
Agent Reasoningも改善します。
ModelはUser Intentをより正確に理解するようになるでしょう。
しかしDeterministic API Securityの価値はなくなりません。
Prompt Injectionが成功してもAuthorizationが働く。
ModelがObject IDをHallucinateしてもObject-Level Access Controlが働く。
AgentがAdmin Toolを選んでもFunction-Level Authorizationが働く。
Compromised Accountが大量利用を試みてもQuotaが働く。
そのためAI API Securityは、AI Riskを減らす非常にDurableなControlの一つです。
AI API Securityは「新しいDecision Layerを持つTraditional API Security」
AIが変えるのはRequestの生成方法です。
RequestをVerificationする必要性は変わりません。
ModelはIntentをInterpretし、ActionをDynamicに選択できます。
このFlexibilityがAIの大きな価値です。
同時に、Model OutputをTrusted Internal Trafficとして扱ってはいけない理由でもあります。
Sensitive API Operationでは、今後も同じ質問が必要です。
誰がこのRequestを送っているのか。
何を実行するPermissionがあるのか。
どのObjectへAccessできるのか。
どのPropertyを受け取ってよいのか。
どの程度Resourceを消費できるのか。
どのDownstream Serviceへ到達できるのか。
Requestが間違って生成されたらどうなるのか。
AIがAPIを大幅に使いやすくすることはできます。
APIを悪用しやすくしてはいけません。
AI API Securityに関するよくある質問
AI API Securityとは何ですか？
AI API Securityとは、Model Endpoint、Application API、Agent Tool、Credential、Connected ServiceをUnauthorized Access、Data Exposure、Resource Abuse、Unsafe Model-Driven Actionから保護することです。Traditional API SecurityにPrompt Injection、Tool Calling、Autonomous WorkflowなどAI固有のRiskを組み合わせます。
通常のAPI Security ControlはAI Applicationでも必要ですか？
はい。Broken Object Level Authorization、Broken Authentication、Broken Object Property Level Authorization、Unrestricted Resource Consumption、Broken Function Level Authorizationなどは、AI ApplicationからAPIを利用する場合でも重要です。
AI ModelにAPI Authorizationを任せても安全ですか？
ModelはUser IntentのInterpretには役立ちますが、Sensitive API AuthorizationはApplicationまたはDownstream APIによってDeterministically Enforceするべきです。Permission ControlをModel Reasoningだけへ依存させるべきではありません。
AI API Keyはどのように保護すべきですか？
API KeyはPrivileged Credentialとして扱い、可能な限りModel ContextやClient-Side Codeの外部に保持し、必要なServiceやEnvironmentだけへScopeし、Exposureが疑われた場合にRotationやRevocationできるようにします。
AI ApplicationにおけるBroken Object-Level Authorizationとは何ですか？
Authenticated UserがAI ApplicationやDownstream APIを通じ、自分にはPermissionのないObjectへAccessできる状態です。Natural Language Interfaceを使用していてもObject-Level Permission Checkは必要です。
Prompt InjectionはAI APIへどのような影響を与えますか？
Prompt InjectionによってAgentが実行しようとするAPI OperationをManipulateできます。しかしStrong Backend Authorizationがあれば、ModelがManipulatedされても新しいPrivilegeを作らないようにできます。
AI APIでRate Limitが特に重要なのはなぜですか？
AI Inferenceは高Costになる場合があり、一つのRequestから複数Model CallやTool Operationが発生する可能性があります。Uncontrolled UsageはService Degradation、Denial of Service、Financial Lossにつながる可能性があります。
Internal AI Tool APIにもAuthorizationは必要ですか？
はい。UserやExternal ContentからInfluenceを受けるAI ModelがAPIへ到達できるなら、Internal NetworkにあるだけではTrustedとは言えません。Sensitive Internal ToolはIdentityとAuthorizationを独立してValidationするべきです。
AI APIをどのようにPenetration Testしますか？
Traditional API AssessmentとAI-Specific Attack Pathを組み合わせます。Authentication、Object / Function Authorization、API Key Handling、Tenant Isolation、Model-Driven Tool Call、Resource Consumption、Prompt Injection Impact、Service-to-Service Trust、Chained API Actionなどを評価します。
最も重要なAI API Security Principleは何ですか？
最も重要な原則は、
Model OutputはRequestであり、Authorizationではない
ということです。
Sensitive APIはUser、Agent、Service Identityが本当にそのOperationを実行するPermissionを持つかを独立して判断する必要があります。
