AIエージェントは、従来のアプリケーションセキュリティでよく知られていた認証と認可の問題を、より複雑なものへ変えています。
通常のソフトウェアでは、ユーザーからリクエストを受け取り、本人確認を行い、権限をチェックし、あらかじめ決められた処理を実行します。
AIエージェントは、その途中に入り込みます。
ユーザーの高レベルな目的を解釈し、データを取得し、利用するツールを選び、複数の中間判断を行い、場合によっては一つのリクエストから複数の操作を実行します。
そこで重要になるのが、
AIエージェントが何かを実行するとき、その権限は誰のものなのか？
という問題です。
ユーザーなのか。
エージェント自身なのか。
アプリケーションなのか。
Service Accountなのか。
あるいは、それらの組み合わせなのか。
NISTも2026年にSoftware and AI Agent Identity and Authorizationを専門的に扱う取り組みを開始し、AIエージェントについてIdentification、Authorization、Auditing、Non-Repudiationをどのように扱うべきか検討しています。
AIプロダクトのセキュリティ原則は、Architectureが複雑になっても明確であるべきです。
モデルが「この操作は適切だ」と判断しただけで、新しい権限が生まれてはいけません。
AuthenticationはIdentityを確認します。
AuthorizationはPermissionを決定します。
LLMはIntentを理解するために利用できますが、重要なPermission DecisionはModelの外側でDeterministicかつAuditableに実行する必要があります。
AIが実際に行動できるほどIdentityは重要になる
質問に答えるだけのChatbotは、直接的なAuthorityが限定されています。
しかしToolへ接続されたAI AgentはUserの代わりに実際のOperationを実行できます。
Documentを読む。
Support Ticketを作る。
Recordを変更する。
Source Repositoryへアクセスする。
別のBusiness SystemでWorkflowを開始する。
そのため、重要なAgent Actionには少なくとも次の情報が必要です。
誰がWorkflowを開始したのか。
どのAgentがOperationを実行したのか。
Downstream Systemは誰のPermissionでAuthorizationしたのか。
この三つが曖昧になると、Security Boundaryも曖昧になります。
Backend Logに、
ai-service performed update
としか残っていなければ、技術的には正しくてもSecurity Investigationには不十分です。
どのUserがそのActionを引き起こしたのか。
そのUserに本来Permissionがあったのか。
そこまで追跡できる必要があります。
AuthenticationとAuthorizationは別の問題
Authenticationが答えるのは、
「このActorは誰か？」
です。
Authorizationが答えるのは、
「このActorは何を実行してよいか？」
です。
AI Applicationでは一つのInteractionに複数のIdentityが参加するため、この区別がさらに重要になります。
UserがSaaSへLoginする。
ApplicationがAI Agentを起動する。
AgentがToolを選ぶ。
ToolがInternal APIを呼ぶ。
APIがDatabaseへアクセスする。
各段階で、どのIdentityとAuthorityが適用されているのか明確でなければなりません。
Userが正しくLoginできたという事実は、Agentが選んだすべてのActionを許可する理由にはなりません。
同様に、AI ServiceがValid Backend Credentialを持っているからといって、そのAIを使うすべてのUserがCredentialの全Capabilityを継承してよいわけでもありません。
AIエージェントにはPermission Chainが存在する
AI Agent Securityは、一回のLogin EventではなくPermission Chainとして考える方が理解しやすくなります。
Human Userまたは別SystemがOperationを開始する。
RequestがAI Applicationへ入る。
ApplicationがAgentへTool Setを提供する。
各Toolが別Systemへ特定Identityでアクセスする。
最終的にDownstream Systemが何を実行できるか決める。
安全な設計では、このChain全体でAuthorityを狭く維持します。
危険な設計では、途中でPrivilege Jumpが発生します。
たとえばOrdinary Userが自分のDocumentだけをReadできるとします。
ところがAI Agentが、すべてのUser FileへアクセスできるShared Administrator CredentialでDocument Serviceを呼び出す。
この瞬間、Limited UserからGlobal Data Accessへつながる経路が作られています。
これがAI AgentにおけるExcessive Permissionの典型です。
User IdentityはAI Layerを越えて維持する
強いAI Agent Architectureでは、元UserのSecurity Contextをできる限り維持します。
EmployeeがEnterprise Assistantへ、
「自分の現在のProjectをまとめて」
と依頼したとします。
AgentがDocument Retrieval Toolを呼び出す。
そのToolは、AI Service Accountが読める全Projectを検索してはいけません。
そのEmployee自身がAccess可能なProjectだけを検索すべきです。
次にUserが、
「Project Statusを更新して」
と頼んだ場合も同じです。
BackendはそのUser自身にUpdate Permissionがあるかを確認します。
AI Interfaceが、通常Applicationより広いAuthorization Universeを作ってはいけません。
Agent IdentityとUser Identityは同じではない
一方で、Agent自身にIdentityが必要になるArchitectureもあります。
これはUser Identityを置き換えるという意味ではありません。
二つのIdentityには別の役割があります。
User Identityは、
誰のためにOperationが行われているか
を示します。
Agent Identityは、
どのAutomated Actorが実際にOperationを実行したか
を示します。
Production SystemではHuman、Scheduled Job、複数AI Agentが同じRecordを変更する場合があります。
Audit Logでは、それらを区別できる方がSecurity Investigationに有利です。
理想的には、一つのActionに、
Initiating User
と
Acting Agent
の両方を関連付けられるべきです。
Application Identityはさらに別のLayerになる
多くのAI SystemはApplication IdentityやService Identityも使用します。
InfrastructureへアクセスするMachine Credentialです。
Service Identity自体が危険なのではありません。
問題はBroad Service Identityが、すべてのAI Userに対する実質的Authorization Layerになった場合です。
AI Assistantが、すべてのCRM Accountを読める一つのService Credentialを使っているとします。
Frontendでは各Userを正しくAuthenticationしています。
しかしCRMが見るのはShared AI Serviceだけです。
User-Level Authorizationを別のLayerで維持しなければ、Role BoundaryやTenant Boundaryが失われます。
Model CapabilityとAuthorizationを分離する
AI ModelがAdministratorの仕事を理解できるからといって、Administrator Actionを実行できるべきだという意味にはなりません。
Accountを削除すればSupport Problemが解決するとModelが正しく推論したとしても、それはDeletion Permissionを証明しません。
これは非常に重要な区別です。
Reasoning CapabilityとApplication Authorityは別です。
LLMはRecommendationを作れます。
BackendがOperationを許可するか決めます。
Model Capabilityが将来どれだけ強くなっても、この原則は変わりません。
LLMを最終Authorization Layerにしない
危険なPatternの一つはPermission RuleをSystem Promptだけに書くことです。
たとえば、
「Accountを削除できるのはAdministratorだけ」
とAgentへInstructionする。
通常は従う。
Testingでも問題なく見える。
しかしこれはStrong Access Controlではありません。
Prompt Injection。
Context Manipulation。
Model Error。
将来のBehavior Change。
こうした要素がModel Decisionへ影響できます。
安全なBackendでは、Deletion Requestを受け取った後で、
Authenticated User、
Role、
Target Account、
Business Rules、
Required Approval
をCode側で確認します。
Checkに失敗したら、Modelが何をRequestedしてもDeletionは実行しません。
PromptはPolicyをModelへ説明します。CodeはPolicyをSystemへEnforceします。
System PromptはBehaviorをGuideできるがPermissionを定義しない
System Promptは不要ではありません。
AgentへExpected Operationを伝えられます。
不要なTool Useを減らせます。
Workflowを理解させられます。
しかしConfidentialityやAccess Controlを維持する最終責任を持つべきではありません。
Prompt InstructionはBehavior Optimizationです。
Deterministic AuthorizationはSecurity Boundaryです。
Least PrivilegeはAgent Levelから始める
Least Privilegeは、Model FailureのImpactを小さくできるためAI Agentで特に重要です。
Public Documentationだけを読めるAgentと、
Production DataをRead、Modify、DeleteできるAgentでは、
同じModelを使っていてもRisk Profileがまったく違います。
ToolやExtensionは、Workflowに必要な最小限だけAgentへ提供するべきです。
「便利だからすべてのToolをUniversal Assistantへ接続する」という設計は避ける方が安全です。
ConvenienceはAuthorityを増やします。
AuthorityはAttack Surfaceを増やします。
Agent Permissionを現在のTaskへ合わせる
さらに強いArchitectureでは、PermissionをTask-Specificにできます。
一つのAI Platformが、
Document Research、
Customer Support、
Account Administration、
Deployment Operations
を扱うとしても、すべてが同じAuthorityを必要とするわけではありません。
Research TaskならRead Access。
Drafting TaskならTemporary Content Creation。
PublishingならSeparate Permission。
Administrative ChangeならAdditional Authorization。
一つのAgentへすべてのCapabilityをPermanentに与えるより、Current Workflowに必要なCapabilityだけをProvisionした方がManipulation時のImpactを小さくできます。
Read PermissionとWrite Permissionを分ける
AI WorkflowはState ChangeよりInformation Retrievalの方が多いことが一般的です。
Support AssistantがCustomer Dataを読む必要はあっても、Customer AccountをModifyするPermissionまで必要とは限りません。
Coding AssistantがRepositoryを読む必要はあっても、Production Deployment Permissionは不要かもしれません。
ReadとWriteを分離することで、非常に実用的なContainment Boundaryを作れます。
Destructive Actionには強いAuthorizationが必要
Data Deletion。
Permission Change。
Ownership Transfer。
Irreversible Operation。
これらを通常のRead Operationと同じControlで扱うべきではありません。
AI Agentが正当にそのFunctionalityを必要としても、より強いControlを追加できます。
Explicit Authorization。
Recent Reauthentication。
Contextual Confirmation。
Human Approval。
重要なのは、すべてのActionへFrictionを追加することではありません。
間違ったDecisionのImpactが大きい場所へ強いControlを置くことです。
Human ApprovalはAuthorizationの代替ではない
Human Approvalは有効なSecurity Controlです。
しかしAccess Controlを置き換えるものではありません。
Ordinary UserがAI AgentへAdmin-Only OperationをRequestさせたとします。
Applicationが、
「続行しますか？」
とConfirmationを表示する。
UserがYesを押す。
これだけでOperationが実行されるなら、Securityは壊れています。
UserはConfirmation Buttonを押すことで、自分に存在しないPrivilegeを作ることはできません。
Authorizationが最初です。
Human Confirmationが答えるのは、
「Authorized Userは本当にこのOperationを意図しているか？」
です。
Authorizationが答えるのは、
「そのUserにはそもそもOperationを実行するPermissionがあるか？」
です。
AI Agent AuthorizationはObject-Awareでなければならない
Functionを実行できるかだけでは不十分です。
どのObjectへ作用するかも確認する必要があります。
UserにupdateProjectを実行するPermissionがあっても、すべてのProjectを変更できるとは限りません。
CustomerがInvoiceを取得できても、他CustomerのInvoiceまで取得できるとは限りません。
Modelは完全にValidなObject Identifierを生成しながら、Unauthorized Resourceを指定する可能性があります。
そのためTraditional API Securityと同じObject-Level Authorizationが必要です。
Tenant BoundaryはAI Workflowを通して維持する
Multi-Tenant SaaSでは、この原則が特に重要です。
一つのAI AssistantがShared Infrastructureから数百、数千OrganizationをServicingする可能性があります。
AgentがGlobal Service AccountでBackendへアクセスすると、Tenant IsolationがAI Layer内のApplication Logicだけに依存してしまいます。
これはFragileです。
Tenant IdentityはDownstream Authorizationまで維持するべきです。
Tenant AがRecord Searchを依頼したら、Tenant AにAuthorizedされたRecordだけがSearch Candidateになる。
Updateを依頼したら、BackendがTarget ObjectがTenant A Scopeに属しているか独立して確認する。
ModelがすべてのPromptとContextでTenant Boundaryを正確に記憶することへ依存してはいけません。
RAG AuthorizationはRetrievalより前に実行する
RAGにも同じ考え方が適用されます。
RAG Systemには異なるUser、Department、TenantのDocumentが入ることがあります。
Semantic Similarityが決めるのはRelevanceです。
Authorizationが決めるのはEligibilityです。
Semantically RelevantなDocumentをすべて取得してから、
「Unauthorized Documentを公開しないで」
とLLMへ頼むべきではありません。
安全なArchitectureでは、最初にAuthorized Document Setを定義し、その中でRetrievalを行います。
これによってSensitive InformationがModel Contextへ入る前にDeterministic Authorizationを維持できます。
AI Agent MemoryにもAuthorizationが必要
Agent MemoryもData Storeの一種です。
Long-Term MemoryにUser、Project、過去Taskの情報を保存するなら、OwnershipとAccess Boundaryが必要です。
Semantic Relevanceだけを理由に別UserのMemoryへアクセスしてはいけません。
Shared Organizational Memoryが正当な場合もあります。
Private Memoryもあります。
Security TeamはPersistent AI Memoryを通常のApplication Data Storeと同じように評価するべきです。
誰が作ったか。
誰がOwnerか。
誰が読めるか。
誰が変更できるか。
どれくらい保持されるか。
Storage Formatが「AI Memory」であるからといってAuthenticationとAuthorizationが不要になるわけではありません。
Toolは独自のSecurity BoundaryをEnforceする
AI ArchitectureではAgentへ多数のToolを公開します。
Database。
API。
External System。
安全なToolは、
「AI Agentから来たRequestだからAuthorized」
と仮定してはいけません。
Downstream SystemがSecurity Policyに基づいてRequestをValidationするComplete Mediationが重要です。
ModelがWrong Toolを選ぶ。
BackendはAuthorizationを確認する。
ModelがWrong Target IDを作る。
Object-Level Authorizationが確認する。
Prompt InjectionがAgent Intentを変える。
Permission Boundaryは維持される。
これがDefense in Depthです。
Tool CredentialはNarrow Scopeにする
Developmentが簡単だからという理由でBroad CredentialをAgentへ渡すべきではありません。
一つのDatasetをReadするToolなら、無関係ResourceへのWrite Permissionは不要です。
一つのBusiness Functionだけに使うなら、Organization内のすべてのServiceへAccessする必要はありません。
重要なのは、ModelがCredentialを盗まなくてもBroad Authorityを悪用できるということです。
Agentがすでに強いAuthorityを持っていれば、Manipulated ReasoningだけでそのAuthorityを使わせられる可能性があります。
Short-Lived AuthorityでRiskを減らす
Long-Lived Broad CredentialはCompromiseのDurationとImpactを増やします。
AI Agent ArchitectureではContextual Authorizationを活用できます。
Permanent Broad Accessを与えるのではなく、特定Workflowへ限られたTaskやPeriodだけPermissionを発行するDesignです。
原則は単純です。
Agentに今必要なAuthorityを与える。将来必要かもしれないAuthorityすべてを与えない。
Delegated Authorizationの意味を明確にする
AI AgentはHuman Userの代わりにActionすることがよくあります。
これはDelegated Authorizationです。
しかし、
「このUserはOperationを実行できる」
と、
「このAgent自身が独立してOperationを実行できる」
は同じではありません。
Personal AssistantはAuthenticated UserのMeetingだけScheduleできるかもしれません。
Internal Automation Agentは特定Employeeと関係なくOrganization Authorityを持つ場合があります。
Deployment AgentはApproved Release Workflow後にのみActionできるかもしれません。
これらのTrust ModelをGenericなagent token一つで曖昧にしてはいけません。
Userの代わりに動くAgentがPrivilegeを増やしてはいけない
安全なDefaultは、
DelegationによってAuthorityを増やさない
ことです。
Human User自身が直接AccessできないResourceなら、そのUserのためにActionするAI Agentも、Privileged Backend経由だからという理由だけでAccessできるべきではありません。
Agentが追加Organization Authorityを持つ正当なWorkflowもあります。
しかしそれは明示的なExceptionとしてStrong Controlの下でDesignされるべきです。
Service Account Designの偶然の副作用であってはいけません。
Independent Authorityを持つAgentには独自Governanceが必要
すべてのAgentがPersonal Assistantではありません。
BackgroundでOrganizationのためにOperationするAgentもあります。
Infrastructure EventをReviewする。
Internal TicketをUpdateする。
Routine Maintenanceを実行する。
この場合Agent自身にAuthorityが必要です。
そのAuthorityは他のPrivileged Machine Identityと同じようにGovernする必要があります。
どのSystemへAccessできるか。
何を実行できるか。
誰がPermissionを変更できるか。
どのLogにActionが残るか。
AccessをどうSuspendするか。
Unexpected Behaviorが起きたらどうするか。
Agentを独立したActorとして扱う必要があります。
Multi-Agent SystemはAuthorizationをさらに複雑にする
Single-Agent Architectureだけでも複雑です。
Multi-AgentではTrust Relationshipが増えます。
一つのAgentがInformationをCollectする。
別AgentがAnalyzeする。
第三のAgentがActionをExecuteする。
問題はPermissionが暗黙的に転送される場合です。
Public Informationだけを読めるResearch Agentが、Execution AgentのAuthorityを自動的に継承してはいけません。
また、別AgentからMessageを受け取ったからといって、それ自体をAuthorization Proofとして扱ってはいけません。
IdentityとAuthorityはAgent間でもExplicitに維持する必要があります。
Agent MessageはAuthorization Tokenではない
Agent AがAgent Bへ、
「UserはこのOperationをApproveした」
と伝えたとします。
Agent Bは、そのNatural-Language SentenceだけをProofとして信頼してはいけません。
AuthorizationにはAuthenticatedでVerifiableなMechanismが必要です。
Natural LanguageはReasoningに使えます。
Security Credentialの代わりにはなりません。
Security SystemがTrustするべきなのはCryptographicまたはDeterministic Authorization Stateです。
Model-Generated Narrativeではありません。
Prompt InjectionをPrivilege Escalationへ変えない
Prompt InjectionはAuthorizationをModel外部へ置くべき最も強い理由の一つです。
AttackerがAgentをManipulateしてPrivileged ResourceへAccess Requestさせたとします。
BackendがAuthenticated UserのPermissionを独立して評価すれば、Requestは失敗します。
ModelはManipulatedされた。
しかしSecurity Boundaryは生き残った。
Security Objectiveは、
Agentを絶対にManipulateできなくすることだけではありません。
より重要なのは、
Manipulationが新しいAuthorityを自動的に生み出さないことです。
Prompt Injection DefenseとAuthorizationは別Layer
Prompt-Injection DefenseはUnwanted Model Behaviorを減らそうとします。
Authorizationは、そのBehaviorが発生した後に何が起こせるかを制限します。
そのためApplicationはPrompt Injection ResistanceがPerfectでなくても、重要なSecurity Boundaryを維持できます。
Injected Instructionが別UserのConfidential Recordを要求させる。
Retrieval APIがRejectする。
AttackはAuthorization Layerで止まる。
これは、
「Model自身が怪しいRequestだと認識して拒否すること」
だけに依存するよりはるかに強いArchitectureです。
Excessive PermissionはModel ErrorのImpactを増幅する
同じModelを使う二つのAgentがあるとします。
一つはPublic DocumentationへのRead-Only Access。
もう一つはProduction Administrator Access。
同じReasoning Errorが起きてもImpactはまったく異なります。
そのためPermission Architectureは、AI Riskを制御する最も効果的な方法の一つです。
Perfect Modelがなくても、Bounded Systemは作れます。
Sensitive TransitionごとにAuthorizationする
Long Agent Workflowの最初に一回だけAuthorizationして、その後すべてをTrustedとするのは危険です。
UserがAuthorized Taskを開始する。
Agentが10個のActionを実行する。
最初のRequestが正当だったから、その後10個もすべて正当だと仮定する。
WorkflowがBranchすると、このAssumptionは壊れます。
Agentは新Informationを発見します。
Unexpected Toolを選ぶかもしれません。
Target Objectが変わるかもしれません。
後のActionのImpactが最初よりはるかに高い可能性があります。
Sensitive Transitionは、そのActionの内容に合ったAuthorizationを受けるべきです。
Autonomous AgentほどAction-Level Authorizationが重要
AgentのAutonomyが高くなるほど、
「最初のUser Approvalが後のすべてをAuthorizeする」
と考えるのは危険になります。
Userが、
「Customer Accountを整理して」
と依頼したとします。
Account Metadataを読む。
Ownershipを変更する。
Duplicate Accountを削除する。
CustomerへMessageを送る。
これらはまったく異なるActionです。
High-Level Goalが、Technically RelatedなすべてのOperationを自動的にAuthorizeしてはいけません。
AuthorizationはSpecific Capability Boundaryへ結びつける必要があります。
Impactに応じてApprovalを強化する
Low-ImpactでReversibleなActionは比較的少ないFrictionで実行できます。
Read-Only LookupならAutomatic。
Draft EditingならOrdinary User Authorization。
External PublishingならConfirmation。
Account Permission ChangeならStronger Verification。
すべてのActionへ同じTrust Levelを設定する必要はありません。
これがGraduated Authorityです。
Approval Fatigueを防ぐ
すべての小さなTool CallにConfirmationを要求するとAgentは使いにくくなります。
同時にSecurityも弱くなることがあります。
何十回もHarmless RequestをApproveしているUserは、内容を読まなくなります。
本当に重要なSecurity DecisionとRoutine Actionが同じ見た目になるからです。
Human Attentionは、User Intentが最も重要になるHigh-Impact Operationへ集中させるべきです。
Security ControlはConstant FrictionではなくMeaningful Frictionを作るべきです。
Permission BoundaryをUserにも理解できるようにする
Agent Interfaceは重要なAuthorityを可視化するべきです。
現在AgentがReadだけしているのか。
Stateを変更するのか。
External SystemへContactするのか。
別PersonやShared Workspaceへ影響するのか。
Production Environmentを変更するのか。
Userが理解できればInformed Approvalが可能になります。
ただし最終Authorization自体はDeterministic Application Controlに残します。
UIはそのControlが何を許可しようとしているのか理解させるためのLayerです。
High-Risk ActionではFresh Authenticationが必要になる場合がある
Long-Running AI Sessionでは、一回LoginしたUser Sessionが長時間続く場合があります。
その後AgentがHighly Sensitive Actionを実行しようとする。
Riskによっては、最初のAuthenticationだけでは不十分です。
Recent ReauthenticationやStronger Identity Confirmationが必要になるOperationもあります。
これはAI固有ではありません。
しかしAI Workflowは直接User Interactionなしで長時間継続・変化できるため重要性が増します。
Long-Lived ConversationをPermanent Privileged Sessionにしてはいけません。
Agent SessionをPermission Containerにしない
Conversation StateにはPreferenceやContextを保存できます。
しかしPrivilege Proofにしてはいけません。
Model Memoryに、
「このUserはAdministrator」
と残っていることは、Authenticated SessionがAdmin Roleを証明することと同じではありません。
以前のConversationでSensitive ActionがApprovedされたというNatural-Language Memoryも、別Contextでの後のActionを自動的にAuthorizeする理由にはなりません。
Authorization StateはSecurity State管理用Systemへ置く。
Natural-Language MemoryはModel Contextへ置く。
混ぜるとBoundaryが脆くなります。
CredentialをModel Context外へ置く
AgentがToolへ到達するためCredentialが必要でも、Model自身がRaw Secretを見る必要は通常ありません。
BackendがCredentialを保持し、Modelの代わりにAuthorized Operationを実行できます。
これによりPrompt LeakageやContext ExposureがCredential Theftへ変わるRiskを減らせます。
Agentに必要なのはCapabilityです。
Underlying Secretそのものではありません。
Authorization MetadataをSecretとして守ろうとしない
RoleやPermission StructureをAIへ教える必要がある場合があります。
有用なReasoningのためには必要かもしれません。
しかしArchitectureは、その情報がSecretであり続けることへ依存してはいけません。
AttackerがRole Modelを理解していてもStrong Authorizationは安全であるべきです。
SecurityはObscurityではなくEnforcementから生まれるべきです。
AuditabilityもAuthorization Architectureの一部
AuthorizationはActionを実行してよいか決めます。
Auditabilityは、実行後に何が起きたか理解できるようにします。
AI Agentは複雑なAction Sequenceを作るため、Audit Trailには十分なContextが必要です。
Initiating User。
Acting Agent。
使用したCapability。
Authorization Decision。
Affected Resource。
Resulting Action。
この情報を関連付けることでUnexpected Autonomous Behaviorを調査できます。
Audit LogではUser IntentとAgent Actionを分ける
Userが、
「古いProject Informationを整理して」
と依頼したとします。
Agentが複数RecordのDeleteを選んだ。
User requested cleanup
だけでは何が実行されたか分かりません。
AI service deleted records
だけでは誰のIntentから始まったか分かりません。
より良いAudit Recordでは、
User XがWorkflow Yを開始した。
Agent ZがOperation Aを選択した。
Authorization Policy Bが許可した。
Object CとDが変更された。
という形でIntentとExecutionを接続します。
Authorization Failureも監視する
AI AgentがPermission Scope外のActionを繰り返し試しているなら、それ自体がSecurity Signalになります。
一度のDenied ActionはHarmless Model Errorかもしれません。
しかし無関係UserのRecordへ何度もDenied Accessしていれば、ManipulationやAgent Logic Errorを疑えます。
Successful Tool CallだけでなくSignificant Authorization FailureもMonitoringするべきです。
Rate LimitingはAuthorizationを補完する
AuthorizationはOperationがAllowedか決めます。
Rate Limitingは一定時間内にどれだけActivityを行えるか決めます。
High-Impact OperationではFrequency LimitがBlast Radiusを小さくできます。
一回だけSensitive Operationを実行できるCompromised Agentも危険です。
同じOperationをThousands Times AutonomousにRepeatできれば、Impactははるかに大きくなります。
Authorization Contextがない場合はFail Closed
AI Workflowは複数Serviceを横断するため、Identity Contextが失われる場合があります。
安全なDefaultは、
Authorization Contextが見つからないからBroad Service-Account AuthorityへFallbackする
ことではありません。
Backendが誰のActionなのか判断できないSensitive OperationでMaximum Permissionを付与するのは危険です。
AuthorityについてのUncertaintyがAuthority Increaseに変わってはいけません。
一つのSuper-Agentを作らない
すべてのBusiness CapabilityへAccessできるUniversal AgentはProductとして魅力的です。
しかし非常に大きなSecurity Boundaryを作ります。
Research AgentはResearchだけをする。
Support AgentはSupport Workflowを担当する。
Deployment AgentはStronger Authorizationの下でDeploymentだけを行う。
このようにCompartmentalizationすれば、一つのAgentがCompromiseまたはManipulationされてもBlast Radiusを制限できます。
Specialized AgentでPermission Modelを明確にする
Specializationの利点は、PermissionをPurposeへ一致させやすいことです。
Document Summarization AgentはRead Access。
Communication Draft AgentはDraft作成のみ、Sendは禁止。
Execution AgentはExplicit Authorization後だけAction。
Universal AgentよりFlexibilityは下がります。
しかしはるかにSecurity Testingしやすくなります。
AI Agent AuthorizationをPenetration Testする方法
AI Agent Security Testingでは、最初にIdentityとPermission Chainを完全にMapします。
User。
Role。
Agent Identity。
Service Account。
Tool。
Downstream System。
最初からModel Manipulationを目指す必要はありません。
まず、
Authorityはどこから来ているのか
を理解します。
各ServiceへどのIdentityがAuthenticationするか。
どのPermissionが付与されているか。
AgentがInitiating Userより広いAccessを持つか。
Backendは誰がActionを開始したか理解しているか。
High-Impact Toolが常にAvailableになっていないか。
RoleによってPermissionが変わるか。
このMapができて初めてAdversarial Testingが意味を持ちます。
同じAgentを複数User Roleでテストする
Role Comparisonは最も価値の高いTestingの一つです。
同じAgentでもLegitimate Permission Setが違えば結果が変わるべきです。
Ordinary UserがShared Service Identity経由でAdmin Actionを得ないか。
Customerが別Tenant Recordへ到達できないか。
Read-Only EmployeeがAI Interface経由でWrite Capabilityを得ないか。
Tool VisibilityだけでなくActual Downstream Executionを比較します。
Hidden ToolでもReachableかもしれません。
Visible ToolでもBackendが正しくRejectできるかもしれません。
重要なのはRuntime Enforcementです。
ModelがPermission以上をRequestした場合をテストする
Security Assessmentでは、Unexpected Model BehaviorでもAuthorizationが生き残るかを意図的に確認します。
ModelがCurrent User Authorityを超えるActionをRequestするControlled Scenarioを試す。
最も強いOutcomeはModelが拒否することではありません。
ModelがRequestしてもBackendがRejectすることです。
これによってSecurity BoundaryがProbabilistic Model Behaviorだけに依存していないと確認できます。
Agent経由のObject-Level Authorizationをテストする
AgentがIdentifierでObjectへAccessできるならOwnershipとTenant Boundaryを確認します。
Natural Languageで別User RecordをRequestできるか。
Modelが別Object Identifierを推論または生成できるか。
Downstream ToolがOwnershipをValidateするか。
Authorization前にRetrievalがMetadataをExposureしないか。
AI Interfaceは、Security-Sensitive Objectへ到達する別Routeにすぎません。
Traditional API Access-Control Testingと同じ視点が必要です。
Delegated Identityをテストする
AgentがUserの代わりにActionする場合、DelegationがUser Restrictionを維持しているか確認します。
OAuth-Style Delegated Identityか。
Backend Service Credentialか。
Custom Policy Layerか。
Downstream SystemはOriginal Actorを知っているか。
一人のUserが別Userに関連するAuthorityをAgentへ使わせられないか。
Technologyそのものより重要なのはSecurity Propertyです。
DelegationがPrivilege Escalationを生まないこと。
Agent-to-Agent Authorizationをテストする
Multi-Agent Systemには専用Testingが必要です。
Low-Privilege AgentがHigh-Privilege AgentへSensitive Workを依頼できないか。
Agent BがAgent AのRequestに関連するAuthorityを独立してValidateするか。
「UserがApproveした」というNatural-Language ClaimでReal AuthorizationをBypassできないか。
一つのCompromised Agentが別AgentをIntended Role以上へ動かせないか。
Revocationをテストする
Permissionは変わります。
Employeeが退職する。
Roleが変わる。
Access TokenがExpireする。
UserがExternal Integration AccessをRevokeする。
Agent Authorizationはこれらを迅速に反映する必要があります。
Cached Agent State。
Persistent Tool Session。
Long-Running Workflow。
こうした場所にOld Permissionが残っていないか確認します。
Revoked Userの古いConversationが、現在のIdentity Systemで削除されたAuthorityを保持してはいけません。
Long-Running Agent Workflowをテストする
Agentは一つのImmediate Requestより長く動くことがあります。
Workflow開始時にValidだったAuthorityが、後のAction実行時にはValidでない可能性があります。
High-Impact OperationではExecution TimeにAuthorizationを再評価する必要があります。
Role Change。
Approval。
External Service。
こうした要素を含むWorkflowでは特に重要です。
Approval Boundaryをテストする
Human Confirmationが必要な場合、本当にBypassできないことを確認します。
BackendはApprovalが発生したProofを要求するか。
UIだけConfirmationを表示して、Underlying Toolは直接呼べないか。
Approval後にAgentがTargetを変更できないか。
Object AへのApprovalがObject BまでAuthorizeしていないか。
Human Approvalは実際に実行されるOperationへBindされて初めて意味を持ちます。
Credential Scopeをテストする
ToolがDownstreamでどのCredentialを使っているか調査します。
Read-Only AI FeatureなのにAdministrator-Level Database Accessを使っていれば、それ自体がRisk Indicatorです。
Functionalityを維持しながらNarrow Permissionへ変更できないか評価します。
Broad Credential AuthorityはPrompt InjectionやModel ErrorのImpactを大きく増やします。
Prompt Injection後のAuthorizationをテストする
Prompt Injection Testingは、Real Permission Boundaryと組み合わせると価値が大きくなります。
Indirect ContentによってAgentがManipulatedされた場合、
別User DataへAccessできるか。
Privileged Toolを呼べるか。
Application Stateを変更できるか。
Backend Authorizationが止めれば重要なDefense Layerは機能しています。
Prompt ManipulationがそのままPrivileged Actionへ変わるならArchitecture Separationが不足しています。
Severityは獲得できるAuthorityで評価する
すべてのAgent Authentication Weaknessが同じImpactではありません。
Loggingの小さなAmbiguityとGlobal Cross-Tenant Accessは違います。
Unnecessary Read AccessとProduction Security Setting Modificationも違います。
Severityを決める重要な質問は、
「AttackerはAgentを通して、通常ならできない何をできるようになったのか？」
です。
これによってAbstractなAI BehaviorをPractical Security Impactへ変換できます。
RemediationではPermission Boundaryを復元する
Agent Authorization Weaknessの修正はBroken Security Propertyへ集中するべきです。
Shared Service AccountがUser-Level AuthorizationをBypassするなら、User ContextをRestoreするかEquivalent Downstream PolicyをEnforceする。
Agentに不要なWrite AccessがあるならPermissionを減らす。
High-Impact OperationがApprovalをBypassするなら、Actual Execution PathへApprovalを移す。
Permission RuleがPromptにしかないならDeterministic Codeへ実装する。
Multi-Agent SystemがNatural-Language Authorization ClaimをTrustしているならAuthenticated Delegationを導入する。
Unauthorized Outcomeを「起こりにくくする」のではなく、Technically Impossibleにする方向へ修正するべきです。
Retestingでは異なるModel Behaviorを試す
Weak RemediationはSystem Promptだけを変更しOriginal Attack WordingをBlockします。
Strong RemediationはAuthorization自体を修正します。
Retestingでは同じRestricted OperationへのAlternate Pathを試します。
Modelが別の表現や別Tool Selectionを使っても、UserがPermissionを持たない限りOperationが拒否されるならBoundaryは強くなっています。
Model BehaviorはProbabilisticです。
Authorizationはそうあるべきではありません。
ローンチ前に安全なPermission Boundaryを設計する
最も修正しやすいAuthorization VulnerabilityはArchitecture Design時点で防げたものです。
AgentをProductionへ入れる前に、何ができるかをMapします。
どのDataを読めるか。
どのRecordを変更できるか。
どのToolを呼べるか。
どのService Accountを使うか。
User IdentityがDownstreamまで維持されるか。
どのActionにStrong Permissionが必要か。
どれにExplicit Approvalが必要か。
Human不在でもAgentがActionできるか。
Prompt Injectionが成功したら何が起きるか。
ProductionにPrivileged Agentを投入してからAuthorizationを再構築するより、Design PhaseでThreat Modelする方がはるかに安価です。
最初にHuman UserのAuthorityを定義する
User-Facing Agentでは、Strong Security ModelはHuman UserのExisting Permissionから始めるのが自然です。
Userは通常Applicationで何ができるのか。
Agentはそれ以上のAuthorityを本当に必要とするのか。
多くの場合、必要ありません。
Agentが変えるべきなのはInterfaceとAutomation Levelです。
User Permission Levelを静かに変えるべきではありません。
次にAgent自身のAuthorityを定義する
一部CapabilityはAgent自身へ属します。
Temporary Analysis Artifactを作れる。
Shared Documentation Indexを読める。
全User向けInternal ServiceへQueryできる。
これらはExplicitに定義する必要があります。
Security Teamが、一つのConversationと切り離してAgent Authorityを説明できるべきです。
Authorityを明確に説明できないAgentは、安全にGovernするのも難しくなります。
次にすべてのTool Boundaryを定義する
各Toolには明確なSecurity Contractが必要です。
何をするのか。
どのIdentityがCallできるか。
どのObjectへ作用できるか。
ReadかWriteか。
どのBackend Credentialを使うか。
Human Approvalが必要か。
External Communicationできるか。
何をLogするか。
これがAgent ArchitectureをTestableにします。
最後にModelが間違ったDecisionをすると仮定する
これは最も有用なArchitecture Testです。
ModelがWrong Toolを選ぶ。
Prompt Injectionが成功する。
Untrusted ContentがReasoningを変える。
UserがAmbiguous Questionをする。
AgentがDangerous ActionをHallucinateする。
その次に何が起こるか。
答えが、
「Modelはたぶん拒否する」
ならSecurity Boundaryは弱いです。
答えが、
「Authenticated UserのAuthorization外のOperationはBackendが必ずRejectする」
なら、Architectureははるかに強力です。
AuthenticationとAuthorizationはAgentic AI Securityの基盤
AI Agentは、これまでDeterministicだったWorkflowへReasoningとAutonomyを追加します。
そのため新しいSecurity Challengeが生まれます。
しかし最も強力なDefenseの基本は新しくありません。
Actorを確認する。
Identityを維持する。
Permissionを制限する。
Sensitive ActionごとにAuthorizationする。
User AuthorityとAgent Authorityを分離する。
Least Privilegeを使う。
ReadとWriteを分ける。
High-Impact OperationにはStrong Controlを使う。
Authorization RuleをPromptだけへ保存しない。
SecretをModel Context外に置く。
重要ActionをLogする。
Remediation後にPermission BoundaryをRetestする。
NISTが2026年にAI Agent IdentityとAuthorizationを専用テーマとして扱い始めたことは、これが単なる理論ではなくEnterprise Securityの中心課題へ移っていることを示しています。
最も重要な原則はシンプルです。
AIは「どのActionをRequestするか」を決めてもよい。
しかし、そのActionがAuthorizedかどうかをAIだけで決めてはいけません。
AIエージェントの認証と認可に関するよくある質問
AIエージェント認証とは何ですか？
AIエージェント認証とは、Workflowに参加するHuman User、Software Agent、Autonomous AI ActorのIdentityを確認するプロセスです。Modern Agent SystemではUser、Agent、Backend Service Identityなど複数Identityが同時に関与する可能性があります。
AIエージェント認可とは何ですか？
特定のIdentityとContextの下で、AI AgentがどのData、Tool、Object、ActionへAccessできるか決定することです。Critical AuthorizationはLLMの判断ではなくDeterministic ApplicationまたはDownstream ControlでEnforceするべきです。
AIエージェントは独自のIdentityを持つべきですか？
多くのArchitectureでは有効です。Agent IdentityがあるとControlとAuditabilityが向上し、同時にOriginal User Identityによって誰のためにActionしているのか維持できます。
AIエージェントはService Accountを使えますか？
使えます。ただしBroad Shared Service AccountによってUser-Level Authorizationが失われるとPrivilege Problemが発生します。User Security Contextを維持し、Minimum Necessary Permissionを使う方が安全です。
Authorization RuleをSystem Promptへ書いてよいですか？
Behavior Guidanceとしては利用できますが、Security-Critical AuthorizationをSystem Promptだけに依存させるべきではありません。Privilege SeparationやAuthorization BoundaryはLLM外部のDeterministic Controlで強制するべきです。
Least PrivilegeはAI Agentへどう適用しますか？
AgentにはTaskに必要なTool、Function、Downstream Permissionだけを提供します。不要なCapabilityを減らすことでUnexpectedまたはManipulated Model BehaviorのImpactを制限できます。
Human ApprovalはAuthorizationの代わりになりますか？
なりません。AuthorizationはOperationを実行する権限が存在するか確認します。Human Approvalは、すでにAuthorizedされたOperationを本当にUserが意図しているか確認します。
AI Agent Permissionはどのようにテストしますか？
User、Agent、Tool、Downstream IdentityをMapし、複数Roleを比較し、Object/Tenant Isolation、Credential Scope、Delegated Authority、Agent-to-Agent Authorization、Revocation、Unexpected Model Behaviorなどを検証します。
Prompt InjectionでAI Agent PermissionをBypassできますか？
Prompt InjectionはAgentが何を試みるかへ影響できます。しかしStrong Downstream Authorizationがあれば、Manipulated Model Behaviorから新しいPrivilegeが生まれることを防げます。
AI Agent Architectureで最も危険なAuthorization Mistakeは何ですか？
Low-Privilege UserがAI Agentへアクセスし、そのAgentがGeneric High-Privilege Identityを使ってDownstream Actionを実行しながら、元UserのAuthorizationを再確認しない設計です。
