セキュリティ・権限・プライバシー

認証・認可・個人情報・攻撃対策

111件の公開項目

• EA · EA-014AIレッドチーム／耐障害運用編Prompt injection / agent hijackingへの耐性はmodel-only refusalではなく、system containmentとrecoveryの問題として扱う。外部文書、Web、メール、RAG、connector、MCP/tool等のuntrusted inputがprivileged action/dataと同一decision loopへ入ることを前提に、least privilege、deter
• EA · EA-015AI監査・証跡設計大全AIシステムの監査可能性は、単一ログの有無ではなく、control/admin、identity/auth、data/retrieval、model request/result、tool/action、human approval/override、artifact/config/model provenance の各planeを横断して、業務上必要な事象を再構成できることとして扱う。
• EA · EA-034Knowledge／RAG工学専門編Enterprise RAGは検索機能ではなく、権限付き知識の派生物を継続的に生成・検索・検証・削除するライフサイクルとして扱う。検索品質、権限、鮮度、根拠提示、安全性は別々に測定する。RAGが回答へ根拠を与えても、取得漏れ、古いindex、権限同期遅延、poisoned knowledge、unsupported synthesisは残り得るため、retriever・generator・citation・lifecycleを分離して評
• EA · EA-043Agent Identity／Non-Human IdentityAgent Identity／Non-Human Identity
• EA · EA-044Delegated AuthorizationDelegated Authorization
• EA · EA-045AI Credential BrokerAI Credential Brokerは、agentへ長期credentialを配布する仕組みではなく、agent/workload identityとauthorizationを確認したうえで、必要なtarget・scope・期間に限定したcredentialを発行・交換する、またはbroker側でcredentialを注入して代理実行する統制パターンとして扱う。SPIFFE、OAuth Token Exchange、Vault等は
• EA · EA-047Agent Policy Enforcement「Agentの禁止操作や許可条件は、LLMの自己判断だけでなく、実行経路上のPolicy Enforcement Pointで強制し、外部Policy Decision Pointにsubject・resource・action・contextを評価させる構成が取れる。OpenID AuthZEN Authorization API 1.0はPDP/PEP間の相互運用境界を標準化している。一方、AI固有のtool意味論やdelegati
• EA · EA-048Sandbox／Code Interpreter運用「AIによるコード実行は、モデル機能ではなくuntrusted workload executionとして管理する。container、gVisor型sandbox、microVMは隔離強度・互換性・運用コストが異なり、いずれも単独で完全な安全性を保証しない。Enterprise運用ではnetworkとsecretをdefault-denyにし、filesystem・syscall/device/capability・CPU/memor
• EA · EA-049Browser Agent専門編「Browser Agentは、Web APIがない／十分でない画面操作を自動化できる一方、ブラウザ制御protocolそのものはagentの意図・権限・安全性を保証しない。企業運用ではWebコンテンツを非信頼入力として扱い、session/credential、action policy、network・file境界、監査、最終業務状態の検証をモデル外の制御層に分離する。WebArenaやWorkArena等の成績は比較評価には使える
• EA · EA-051AI Telemetry標準編“OpenTelemetry and W3C Trace Context provide a strong interoperability substrate for AI telemetry, but AI-specific semantic conventions remain an evolving layer. As of 2026-09-14, OpenTelemetry’s GenAI conventions have m
• EA · EA-053AI Incident Response「AI Incident Responseは既存のサイバーIRを置き換える別制度ではない。2026年時点の有力な実務方向は、既存IRへAIシステムの観測性・制御性・version provenance・model/data/tool/agent経路の分析を追加することである。ただしAI固有incident managementの標準化は進行中であり、特定のtaxonomyやreporting schemaを普遍的完成標準として扱うべきで
• EA · EA-054AI Kill Switch／Rollback設計「AIのKill Switchは、単一の『全停止ボタン』よりも、異常部分を最小単位で隔離し、必要に応じて全体停止へ拡大できる制御面として設計する方が実務的である。Rollbackにはknown-good revisionの保持とversion provenanceが必要だが、モデルやworkflowの切戻しは、既に外部世界へ生じた副作用を自動的に取り消すものではない。2026年時点で、model・prompt・workflow・tool
• EA · EA-056AI Asset Inventory／AI-SBOM「AI Asset Inventoryでは、SPDXやCycloneDXのAI/ML対応BOMを供給網の機械可読スナップショットとして利用できる。ただし、それだけで企業内のAI利用を完全に棚卸しできるわけではない。prompt、外部API、MCP/tool、RAG corpus、provider-side deploymentなど、実行時に変化する依存をRuntime Asset Registryで補完し、UNKNOWNを明示したまま継
• EA · EA-057Shadow AI発見編「Shadow AIの発見は、未承認AIを一度のスキャンで完全列挙する機能ではない。SSE/CASB、endpoint/process、browser/IDE、cloud/SaaS/API auditなど複数の観測面から“観測された利用”を集め、承認台帳と突合して初めて運用上のShadow AI inventoryになる。アプリへの通信観測、実際のprompt内容観測、機密データ露出の確認は別の証拠レベルとして扱う。」
• EA · EA-061AI向けData Classification「AI向けデータ分類は、従来の機密区分を捨ててAI専用ラベルへ置き換える作業ではない。既存の正式な分類を起点に、prompt、retrieval、tool、memory、output、logというAI固有のデータ移動面へ分類情報を伝播し、必要に応じて再検出・再評価する。自動検出結果は有力なsignalだが、完全な分類やcomplianceの証明ではない。classification、authorization、destination p
• EA · EA-062Data Residency／Sovereign AI「データレジデンシーは『リージョンを選べばすべてがその地域に留まる』という単一機能ではない。保存、推論、ルーティング、ログ、監視、バックアップ、検索/grounding、エージェント実行などで適用範囲が異なり、provider・model・deployment type・featureごとに確認が必要である。Sovereign AIはさらに法的管轄、運用統制、供給網、技術的自律性などを含み得るため、Data Residencyと同義に扱
• EA · EA-063AI Privacy Engineering「AIのプライバシー対策は、PIIを見つけて黒塗りすることだけではない。まず業務目的に不要な個人情報を取得・検索・転送・保持しない。必要な情報には、検出、仮名化、削除、暗号化などを目的に応じて使い分ける。『検出されなかった』『anonymizeという関数を通した』ことだけで匿名化済みとは判断できない。識別可能性は周辺情報や復元鍵、外部データとの結合でも変わるため、入力、RAG、tool、memory、出力、ログまで処理面ごとに確認する必
• EA · EA-064AI Data／Memory Lifecycle専門編「Enterprise AIのmemory lifecycleは『覚える／忘れる』の二値ではない。session/raw event、派生summary、durable memory、revision、retrieval index、application state、logなどに別々のretentionとdelete semanticsが存在し得る。delete/resetを運用要件にする場合は、対象scopeとartifact、期待
• EA · EA-065AI × Records Management／eDiscovery「AI会話・生成物・Agent実行は、AIで生成されたという理由だけで一律に記録または廃棄対象になるわけではない。記録性は組織の業務・法令・保存方針に従ってartifact単位で判断し、legal holdやeDiscoveryでは、会話、memory、監査ログ、成果物などの実際の保存先を把握して保全・検索・export範囲を確認する。ユーザー画面からの削除、検索不能、provider側retention終了は同じ事象ではない。製品のc
• EA · EA-066Identity-aware／ACL-aware RAG「RAGで元データの権限を守るには、文書にACLを付けて保存するだけでは足りない。検索時の利用者を識別し、その時点で有効な権限と照合して、許可された文書・チャンクだけをLLMのコンテキストへ渡す必要がある。さらに、元データの権限変更が検索インデックスへ反映されるまでには遅延があり得るため、ACL同期の鮮度も認可状態の一部として監視する。『ログイン済み』『検索結果では非表示』『RAG対応』はいずれも、元データと同じアクセス境界が保たれてい
• EA · EA-068Semantic Layer × AI「Enterprise AIの分析では、LLMを生のデータベースschemaへ直接接続するより、組織が定義したmetrics・dimensions・relationships・access rulesを持つsemantic layerを介在させると、AIが推測しなければならない業務意味を減らし、定義をversion管理・監査・評価しやすくできる。これは回答正確性の保証ではない。semantic model自体の誤り・不足・陳腐化、権限設
• EA · EA-071Speech AI大全「Speech AIはSTTやTTSの単体機能ではなく、認識、話者分離、turn-taking、Agent/tool実行、音声合成、interrupt処理までを含む実時間経路として評価する。各機能のavailabilityと品質はmodel、language、region、API modeで異なるため、provider名だけで能力を一般化しない。WER、自然性、会話latency、task success、安全性は別指標として測る。」
• EA · EA-072Vision／Video AI大全「Vision AIは単一能力ではない。OCR、検出、localization、caption、visual reasoning、retrieval、moderation、video temporal analysisを能力単位で評価し、model/API revisionとsource locatorを保持する。専用Vision APIのstructured detector outputとMLLMの自然言語理解は補完関係にあり、片方
• EA · EA-073Forms／Handwriting／Barcode AI「紙帳票をAIへ取り込む処理はOCRだけではない。文字認識、キーと値の対応、チェック状態、手書き判定、バーコード形式とpayload復号を別々に検証する必要がある。読み取れた文字やQRコードは、それだけで業務上の真正性や安全性を保証しない。原画像と抽出結果のprovenanceを保持し、正規化・検証・認可・必要な人手確認を後段に置く。」
• EA · EA-081Fine-tuning／Adapter／Distillation大全「モデル適応には、教師付きfine-tuning、LoRA等のparameter-efficient tuning、量子化併用PEFT、distillationなど異なる経路がある。これらは学習・配備artifactとfailure surfaceが異なるため、“カスタマイズ済み”を一括して扱わない。採用時はbase model、method、training data、artifact、evaluation、availabilityを
• EA · EA-083Semantic／Prompt Cache“Prompt/context caching can reduce repeated-prefix processing cost and latency without reusing an old answer, while semantic response caching may skip inference by reusing an answer for a similar request. The latter ther
• EA · EA-085Streaming／Event-driven AI“Event-driven AI replaces polling with event-triggered execution, but safe operation depends on delivery semantics more than model capability. Assume events can be duplicated, delayed, reordered, replayed, or forged; ver
• EA · EA-087Kubernetes／Private AI「KubernetesはPrivate AIの共通control planeになり得、KServe等によりLLMを含むmodel servingを構成できる。ただしGPU driver/device plugin、network enforcement、model/runtime互換性、capacity、patching、observabilityは組織側の責任となる。『private』は配置場所ではなく、identity・networ
• EA · EA-090Air-gapped AI「Air-gapped AIは、モデルを一度持ち込んでネットワークを切れば完成するものではない。閉域内で推論・RAGを実行できることに加え、モデル、コンテナ、依存package、データ、脆弱性情報を検証付きで持ち込み、内部repositoryから更新・rollback・監査できる供給線が必要である。物理mediaは更新経路であると同時にattack surfaceでもある。」
• EA · EA-102著作権・営業秘密・知財編「米国著作権局はAI出力の保護を人間の寄与に基づき事実ごとに判断する分析を示している。営業秘密は秘密性を維持する合理的努力を含む要件がある。日本での結論やprovider契約は別確認が必要。」
• EA · EA-104AI Supply-chain Security「SLSAはprovenanceとattestationの表現・検証を支えるが、artifactの安全性や品質を単独では保証しない。OpenSSF Scorecardは対象OSS repositoryの時点別check結果であり、全展開の保証ではない。」
• EA · EA-105AI生成コードSecurity「生成コードは、通常のコードと同じく解析・依存関係・secret・license・テスト・人手レビューを通す。CodeQL/Scorecardは検査部品であり、生成コードの安全性・適法性を保証しない。」
• EA · EA-106Automated AI Red Team「PyRITとgarakは生成AI/LLMのリスクprobeを自動化するOSS部品である。probeが通過したことは安全性の証明ではなく、対象・version・fixture・設定に依存する。」
• EA · EA-113Email Agent安全運用「Gmail APIはmessages.sendとdrafts.sendを別methodとして提供するため、draft→検査→明示承認→sendという制御点を設計できる。ただし、APIの存在は宛先正確性、承認、DLP、法的適合、送信後回収を保証しない。」
• EA · EA-114Spreadsheet Agent安全運用「Sheets API v4はセル値・書式・保護範囲などを操作でき、batchUpdateはrequest検証と一括適用を提供する。ただし、同時編集の影響があり、APIのatomicityは式の意味正確性、再計算結果、業務上の正しさを保証しない。」
• EA · EA-116Coding Agent運用大全「GitHub Copilot cloud agentはtaskからrepository作業・PR作成へ接続でき、管理者有効化、repository opt-out、Actions minutes/AI credits等のgateを伴う。Code scanningは別の検出・SARIF/CodeQL層であり、agent生成コードの正しさ・安全性・license適合・merge可否を自動保証するものではない。」
• EA · EA-118Meeting AI Governance「Google Meet REST APIは会議spaceのaccess/moderation、録音・文字起こし設定、member/co-host、attendanceとartifact取得を扱う。これは会議AIの技術的control pointであり、参加者同意、法的適合、要約品質、tenantでの実効可用性を自動保証しない。Meet dataを性能評価へ用いない旨の公式注意もある。」
• EA · EA-119Voice Agent業務運用「Twilio Programmable Voiceの公式Docsは発着信、録音、transcription、AI agent/予約の実装入口を示す。これは音声業務の技術的control pointの証拠であり、本人確認、同意、ASR精度、予約成功、法的適合、human handoffを保証しない。」
• EA · EA-120Transaction／High-impact Action Guardrails「EU AI Act Article 14は高リスクAIのhuman oversightとして、能力・限界の理解、automation biasへの注意、override/reverse、safe stop等を規定する。企業の全transactionを自動的に同一の高リスク分類へ置く根拠ではなく、実運用では法域・用途・権限・不可逆性を別途分類する。」
• EA · EA-121異種LLMマルチエージェント「AutoGen原著は複数agent、LLM/human/toolの組合せ、相互作用のプログラムを示す。異種LLM構成はその実装候補だが、異種化だけで品質・安全・費用対効果が保証されるわけではなく、task別比較が必要である。」
• EA · EA-125Generator–Verifier「Process supervision研究は、MATHの特定条件で中間stepへの検証が有効であると報告する。Generator–Verifierはruntime safetyの設計候補だが、verifier passは任意業務の正しさ・副作用なし・法的適合を保証せず、specと独立評価が必要である。」
• EA · EA-126Planner–Executor異種化「Plan-and-Solve研究はplan→subtask executionの構造と特定推論taskでの比較結果を示す。Planner–Executor異種化は費用・権限分離の設計候補であり、planの完全性、executorの安全性、外部actionの可逆性を自動保証しない。ReActのようなinterleavingも代替設計である。」
• EA · EA-128Adversarial multi-LLM「Adversarial multi-LLMは、攻撃側LLMを用いて対象LLMの有害応答や漏えい等を探索する研究ベースの評価方式である。研究例はあるが、異種化だけで網羅性・安全性・企業tenantでの再現を保証しない。」
• EA · EA-142AWS Strands Agents「Strands Agentsの公式Docsは、AWS発のPython/TypeScript open-source SDKとして、tool、hook、context、execution limit、observability、multi-agent pattern、複数model/cloudの実装入口を示している。SDKの機能記載は、各model・cloud・契約・regionでの可用性やproduction安全性を保証しない。」
• EA · EA-147Copilot Studio「Microsoft LearnのCopilot Studio overview（2026-08-22更新）は、agent・workflow・agent flow・connector・human reviewを一つのlow-code studioで組み合わせ、harness差による能力・課金差、analytics/evaluations、RBAC・cost管理を説明している。tenant・license・environment・conn
• EA · EA-148Google Workspace Studio「Google公式HelpはWorkspace Studioを、Geminiを用いてWorkspaceと一部の他アプリをstarter/step型flowで自動化する機能として説明している。管理者によるGemini有効化、edition・app access・approval・第三者データ共有の条件があり、add-onによるcustom step拡張は2026-09-03更新Docsでlimited previewである。実行品質・監査
• EA · EA-149UiPath agentic automation「UiPathの公式Agents Docsは、agentを確率的・適応的な判断系、RPA robotを決定論的な実行系として対比し、両者と人を組み合わせるagentic automationを説明している。公式Docsの現行導線にはMaestro、Studio Web、connectors、data residency、評価・trace系の項目があるが、製品・license・region・workspace・modelの可用性と実測安全
• EA · EA-151Zapier AI／Agents「Zapierの公式Agentsページは、company knowledgeを与えたspecialized agentが複数appで作業し、activityを監視できる構成を示す。公式トップページにはmanaged connection、app/domain controls、RBAC/SCIM、audit API、log streaming等のenterprise機能が掲げられているが、plan・tenant・connection・実
• EA · EA-152Make「Makeの公式ページは、app・data source・AI modelをvisual/code/promptでつなぎ、AI agents・workflowsをMCP等で構築・管理するvisual automation platformとして説明している。security/complianceやintegration数は公式ページの現行訴求であり、plan・region・MCP・権限・実測品質・費用は別途確認が必要である。」
• EA · EA-153Workato「Workatoの公式Docsは、Agent Studio・enterprise skills・knowledge・guardrailsと、MCPのComposer/Registry/Gateway/Runtime、connectivity・identity・auditability・billing/usageを企業AIのcontrol/execution planeとして案内している。これは公開機能導線の確認であり、license・t
• EA · EA-154Pipedream「Pipedreamの公式サイトとDocsは、AI agentとAPIの間にmanaged auth、prebuilt tools/triggers、raw proxy、MCPを置くConnectを説明し、workflow・event/concurrency・source-available component registryも案内している。企業向けConduitは同サイトでearly accessと記載されるため、plan・proj
• EA · EA-155Temporal「TemporalはLLMではなく、Workflow Executionの状態・Event History・Replay・Activity・Signal・timeout/retryを用いて長時間処理を耐障害化するdurable execution基盤である。公式Docsはsize/throughput・determinism等の限界を含み、author-maintained issueにはretry時の既成功Activity再実行に関す
• EA · EA-159AG-UI「AG-UIは、agentic backendとユーザー向けfrontendの間を、HTTP／WebSocket等の上にイベント駆動・双方向で接続するプロトコルである。イベント仕様1.0は当該資料でDraftと表示されているため、採用時は版・SDK・再接続・認可・表示安全性を個別に確認する。」
• EA · EA-160OpenAPI／Function Calling「OpenAPI 3.1.0はHTTP APIの機械可読なインターフェース記述であり、function callingはproviderのモデルがアプリケーションへ外部処理の呼出しを要求する実行境界である。OpenAPIをfunction toolへ写像することは可能な設計選択だが、版・operation・schema・認証・実行結果・side effect policyを別途固定し、同一仕様とは扱わない。」
• EA · EA-161Webhook／Event protocol「WebhookはHTTP等による通知・受信の配置であり、全実装に共通する配送保証ではない。CloudEvents v1.0.2はevent context/data、specversion、source/id、format、protocol bindingを定義するが、exactly-once、順序、retry、署名、認証、業務処理の原子性は個別契約として設計・検証する。」
• EA · EA-162OAuth／OIDC × Agent「OAuth 2.0は限定的なHTTPリソースアクセスの委任、OIDCはOAuth上でEnd-Userの認証結果とclaimsを扱うidentity layerである。Agent運用では、human／workload／service identity、resource/audience、scope、delegation chain、tool action、approvalを別々に結び付ける必要があり、OAuth／OIDCの成功だけではa
• EA · EA-163SCIM × AI「SCIM 2.0（RFC 7643/7644）は、Users／Groups等のidentity resourceをHTTPでプロビジョニング・管理する標準である。AIでは、人員異動をAgentやtool accessへ反映する設計の基盤になり得るが、agent資産・権限・token・memoryの無効化までをSCIMが保証するわけではない。」
• EA · EA-164LiteLLM「LiteLLMは、Python SDKとProxy Serverを通じて複数LLM providerを共通インターフェースへ寄せ、routing／retry／fallback、認証、ログ、guardrail、spend管理等を提供すると公式リポジトリで説明している。provider互換性、品質、価格、データ処理、fallback安全性はrelease・model・設定単位で再確認する。」
• EA · EA-165OpenRouter「OpenRouterは、複数model/providerへのAPIアクセスを一つのrequest形状へ寄せ、tool callingではproviderの実装に応じて透過・変換・YAML化を行うと文書化している。Auto Routerのallow／exclude／cost tier等はroute制御であり、モデル品質・価格上限・データ境界・SLOの保証ではない。」
• EA · EA-166AI Gateway群「AI Gateway群は、複数providerへの接続を集約し、routing／fallback、認証、rate limit、logging、cost、cache、policy等を実装するcontrol-plane群である。LiteLLM、OpenRouter、Vercel、Cloudflareの公式資料は機能境界が異なるため、共通機能と製品固有の実装・契約・版・地域・設定を分離して評価する。」
• EA · EA-217DeepgramDeepgramの音声対話では、API世代・model・入力形式を固定し、文字列の確定、発話終了、生成、実再生、業務操作の認可を分けて管理する。
• EA · EA-218ElevenLabs Audio／Voice AgentsElevenLabsのTTS・STT・dubbing・sound・Voice Agentはmodelと製品ごとに評価し、接続権限、声素材の権利、商用条件、再生と保持を分ける。
• EA · EA-222Slack／Teams／ChatをAgentの業務面にするチャット上の入力・承認・通知・handoffを業務操作へ安全に接続できるか。署名やボタン押下だけを本人認可・最終承認へ転用しない。
• EA · EA-005MCP実践辞典 — Model Context Protocolを「共通コネクタ」ではなく、server/client/host、transport、authorization、tool capability、server trust、supply chain、auditを分離した企業運用契約として整理する「MCPは、AIアプリケーションと外部のデータやツールを共通形式で接続するためのprotocolであり、接続先やツールの安全性を自動的に保証する仕組みではない。2026-07-28仕様ではstateless化とOAuthのhardeningが進み、HTTP接続ではresource-bound tokenや段階的scope取得を扱える。しかし、どのMCP serverを信用するか、どのtoolをmodelへ見せるか、実行をpolicyや人
• EA · EA-238PII検出・匿名化・Redaction部品PII検出器とredaction/anonymization処理は、入力から識別子を見つけて変換するための部品であり、それだけで「匿名化済み」「規制適合」「再識別不能」を保証するものではない。検出対象、言語、文脈、データ形式、しきい値、変換方式、復元鍵・対応表、ログやキャッシュなどの残存コピーを分けて設計・検証する。
• EA · EA-239Content Safety／Moderation Model・APIContent Safety／Moderation APIは、入力や出力を「安全／危険」と最終決定する認可機構ではありません。特定のモデル、taxonomy、threshold、対応modalitiesと言語の下で、ポリシー判断に使う分類信号を返す部品です。組織側では、この信号をどの条件でblock、allow、transform、human reviewへ接続するかを別に定義します。
• EA · EA-001個人版／法人版クロスウォーク — plan/organization/modeをデータ保護・保持・管理権限・利用可能性・課金/上限・高度機能の条件に分解して比較する。「個人向けと法人向けAIの差は、使えるモデルや機能の数だけでは決まらない。データが学習に使われる既定値、保持・削除、管理者権限、接続先の認可、契約ごとの課金方式、管理対象ID、地域や段階的ロールアウトまでを分けて確認する。同じ製品名・同じモデル名でも、実際に使える能力やデータ境界はaccount、workspace、contract、mode、regionによって変わり得る。」
• EA · EA-002Microsoft AI系統編 — Microsoft Copilot / Copilot Studio / Microsoft Foundry / GitHub Copilot / Microsoft Graph・SharePoint・Teamsを「一つの製品」ではなく相互接続する複数のAI運用面として記述するための境界地図「Microsoftの法人向けAIは、一つのCopilot製品ではなく、複数の運用面が接続した系統として見る方が安全である。Microsoft CopilotはMicrosoft 365の権限とGraphを使う利用者面、Copilot Studioは業務エージェントを組み立てるmaker面、Microsoft Foundryはモデル・ツール・実行・観測を扱うpro-code面、GitHub Copilotは開発者向けの別管理面を持つ。こ
• EA · EA-003Apple Intelligence／オンデバイスAI編 — Apple Intelligence、Foundation Models、Private Cloud Compute、App Intents、Core ML/Vision、MLXを「AppleのAI」という一枚岩ではなく、実行場所・開発者API・privacy boundary・action integration・古典ML/研究基盤に分解する運用地図「AppleのAI運用は『オンデバイスかクラウドか』の二択では捉えにくい。Apple Intelligenceには端末上で動くFoundation Modelと、より大きな処理をPrivate Cloud Computeへ送る経路があり、2026年のFoundation Models frameworkはさらに他のモデル提供者を共通APIへ接続できる。Private Cloud Computeは通常のクラウド推論とは異なるstatele
• EA · EA-009BOUNDED_CLOSEFor self-hosted LLMs, pin the model artifact and license, tokenizer/template, quantization, runtime release/commit, serving contract, accelerator/driver, network/egress, authentication/logging, and rollback artifact. Tre
• EA · EA-234Secrets Management × AgentAgentのSecrets Managementは、秘密を保存するだけでは不十分です。raw secretをmodel contextやagent-generated codeへ直接渡さず、必要なidentity・destination・operationへ限定して権限を仲介する設計を基準にします。
• EA · EA-236ReBAC／Authorization Graph：OpenFGA・SpiceDBReBAC/Authorization Graphは、relationshipに基づくpermission decisionを中央化する仕組みであり、外部identity/session revocation、source-of-truth同期、application enforcementまで自動的に保証するものではありません。OpenFGA/SpiceDBではmodel/schema、relationship data、condit
• EA · EA-237DLP／CASB／SSEで生成AI利用を統制するDLP/CASB/SSEは生成AI利用の可視化、data classification、access control、inline block/redactionを強化できます。ただし「DLP導入済み」を、すべてのprompt、response、file、tool、MCP経路が保護されている証明として扱いません。
• EA · EA-248CDCでAI Knowledgeを更新するChange Data Capture（CDC）は、databaseの変更をAI/RAG knowledgeへ低遅延で届ける経路として利用できます。ただし、CDCを導入しただけでsource databaseからretrieval indexまでexactly-onceに一致するわけではありません。 CDC transportと、document/chunk/embedding/search indexへのmaterialization
• EA · EA-1202Training-data Production／Curation／Annotation／Split Governance「データを大量に集めれば性能が上がる」「重複排除すればprivacy問題が解決する」「annotation agreementが高ければ正解」「train/testを分ければcontaminationはない」と一般化しません。
• EA · EA-173Weights & Biases Weave：AIアプリケーションのトレーシング・評価・運用観測「Weights & Biases Weaveは、AIエージェントやLLMアプリケーションの実行をトレースし、評価・フィードバック・性能／費用観測へ接続するための基盤として利用できる。ただし、記録されたtraceはinstrumentationと送信条件の範囲での観測であり、実行の完全性を自動的に保証しない。評価結果もdataset、scorer、model、prompt等のversionと適用範囲に依存する。Enterprise利用で
• EA · EA-174MLflow：Tracking・Tracing・Registry・artifact accessを別の運用境界として管理するMLflowはTracking、Registry、Tracing等を統合できるが、運用上はTracking Server、backend store、artifact store、authentication/authorization、trace export、model promotionを別の境界として管理する。artifact access方式やtrace export先によってcredential/data boundaryが
• EA · EA-224CRM API × Agent — 書き込み成功を業務上の成功と誤認しない「CRM APIをAgentから操作できること」と「業務上正しく一度だけ更新できたこと」は別です。成功判定はHTTP statusだけでなく、record identity、部分失敗、権限・tenant validation、rate limit/timeout、再試行の冪等性、重要field/associationのreadbackを含めて設計します。providerがtransactional primitiveを提供しても、その原
• EA · EA-231Object StorageをAI正本層にするObject Storage can serve as the canonical byte/evidence layer for AI workflows when the design binds each important artifact to an immutable version identity and content digest, uses provider-supported conditional writes
• EA · EA-233Edge WorkersをAIと業務システムの接着層として使うEdge Workerは、AIへの依頼を受け付け、認証、入力検査、接続先の選択、webhook、応答の転送を行う薄い接着層として利用できます。利用者に近い場所で動いても、モデルや原本データが遠ければ、全体の応答が速くなるとは限りません。長時間処理や業務状態の保存を一回のHTTP処理へ押し込まず、実行時間、永続化、認可、依存障害の境界を明示します。
• EA · EA-253Data Catalog／Metadata Catalog × AIData CatalogをAI/Agentのcontext sourceにする場合、検索結果をそのまま正本データや実行権限として扱いません。 Catalogから取得したcontextには、可能な範囲でentity identity、source locator、metadata revision/freshness、owner、glossary/term、lineage、quality、authorization境界を残します。
• EA · EA-254Event Schema Registry × AgentEvent Schema RegistryはAgentのevent contract gateとして有効ですが、`compatibility PASS`をbusiness semantics、全consumerのruntime成功、publish権限、Agent action安全性の保証として扱いません。
• EA · EA-257Confidential Computing／TEE × AIConfidential Computing／TEEは、定義したthreat modelの範囲でAI workloadのdata-in-useと実行環境をhost/operatorから隔離し、remote attestationをsecret/key releaseの条件にできます。 ただし、TEEやattestation PASSだけでapplication code、GPU、side channel、availability、pro
• EA · EA-258Private Networking／Private EndpointでAIを閉域化するPrivate Endpoint／PrivateLink／Private Service Connectは、AI serviceへpublic internetを経由しないprivate pathを提供できます。ただしendpointを作成しただけでend-to-endの閉域化が完成するとは扱いません。
• EA · EA-261AIサービス間通信をService Mesh mTLS化AI/Agentサービス間のeast-west通信をservice meshで捕捉すると、workload identity付きmTLSによる相互認証と通信暗号化を集中できます。ただしmTLS成立をleast-privilege authorization、全経路のmesh化、application-level安全性とは同一視しません。
• EA · EA-270Explicit State Machine vs Free-form Agent Loopstate machine採用だけでexactly-onceや正当性は保証されず、free-form loopもtermination・権限・checkpoint・readbackを明示すれば統制できる。
• EA · EA-277Data Masking／Tokenization before LLM「LLM前のmasking/tokenizationは機微データ露出を減らすcontrolであり、匿名化や漏えい防止の保証ではありません。必要データだけを送り、検出漏れ、tokenのlinkability、再識別鍵・mapping、quasi-identifier、ログ／cache、出力側を別々に管理します。可逆tokenの復元はLLMから分離した認可済み境界で行います。」
• EA · EA-278Privacy-preserving Computation × AIPrivacy-preserving computationは一つのcontrolではありません。DP、MPC/FHE、federated/remote computation、TEEは異なる境界を保護します。攻撃者、保護対象、許可output、trust assumption、parameter、verification evidenceを明示し、単一PETから匿名性やend-to-end confidentialityを推定しません
• EA · EA-280Retention Policy for AI Conversations／Artifacts「保存先と派生先ごとに保持・利用停止・削除・確認の条件を定め、実行証拠を残す」。一方、「学習に使われないので保存もされない」「応答を消したので全派生物も消えた」「30日なら全製品・全契約で適合」とはしない。
• EA · EA-281Tenant Isolation for Multi-tenant AI「認証由来のテナント文脈を全データ・操作経路へ渡し、保存先と実行主体の認可を強制して分離する」。一方、「テナントIDをプロンプトに書けば分離済み」「索引を分ければ全経路が安全」「専用GPUなら会話やログも分離済み」とはしない。
• EA · EA-282Row／Column-level Security × AI Analytics「実行主体とデータ基盤のポリシーで取得可能な行・列を制限し、AI入力と下流出力にも同じ権限を保つ」。一方、「プロンプトに権限を書けば十分」「RLSがあれば列も匿名化される」「結果0件ならフィルタを外す」「DB設定済みなので出力全体も安全」とはしない。
• EA · EA-283Cache Isolation／Cross-user Leakage対策「再利用を許す範囲を明示し、類似度とは独立した認可区画と失効制御を、保存・検索・同時要求の全経路で強制する」。一方、「IDをプロンプトへ混ぜれば分離済み」「類似度を上げれば漏えいしない」「TTLがあるので権限失効も即時」「修正PRがマージ済みだから全配備が安全」とはしない。
• EA · EA-286Human Queue／Workbasket for AI Exceptions「案件を永続化し、配送・所有・判断・結果反映を分けて追跡する人の作業台を設計する」。一方、「投入できれば解決済み」「visibility timeoutで人の作業も一度だけ」「担当名があれば認可済み」「DLQへ移せば業務完了」「先頭ページが空なら未処理0件」とはしない。
• EA · EA-288Privileged Access Management for Agents「実行主体・対象・操作・期間を限定し、取得から終了までの特権利用を検証可能にする」。一方、「短期トークンなので安全」「人向けPIMをそのままエージェントにも適用可能」「権限を外せば全実行が瞬時に停止」「秘密が見えなければ万能ツールでも問題ない」とはしない。
• EA · EA-289Break-glass／Emergency Access for AI SystemsBreak-glass／Emergency Access for AI Systems
• EA · EA-476通信断を前提にしたAI運用Offline-First AI Operationsは、ネットワークが切れてもモデルを実行できることだけを意味しません。通信断中に利用できるモデル・データ・権限・保存容量を明確にし、古い情報で許してよい処理と停止すべき処理を分け、再接続後に権限と状態を照合してから外部への変更を解放する運用です。推論の継続、業務行為の許可、キューの配送、外部状態の整合は別の成立条件です。
• EA · EA-499Agentへ委譲する権限の範囲と失効Agentへの作業依頼は、利用者や委譲元の全権限を渡すことではありません。現在の実行主体、誰のために動くか、許可された操作と対象、引数、期限、再委譲の条件を明示し、重要な効果の直前に現在の権限を照合します。委譲の履歴が残っていることと、今その操作を許可してよいことは別です。長時間の処理では、開始時の許可、更新・失効、非同期で残った仕事まで管理します。
• EA · EA-506リース失効・タイムアウト・キャンセル後に残る「ゾンビ外部操作」をどう封じるかリース失効・heartbeat timeout・キャンセルは、スケジューラ上の所有権や待機を終わらせるための制御であり、旧実行主体の停止や既送信の外部副作用の取消しを一般には保証しない。可能な対象では単調なgeneration/fencing tokenをmutation境界で原子的に検証し、対応しない外部副作用ではstable operation identity、providerのdocumented idempotency、結果r
• EA · EA-511Risk- and Uncertainty-Aware Human Escalation Router「高影響または高不確実なAI操作では、人間承認の有無だけでなく、承認対象となるexact effect、レビュー担当者の現在権限、要求の期限、resume時の対象状態とauthorizationを結び付けて検証する。承認待ちの容量不足は自動承認で解消せず、backpressureまたはfail-closedを用いる。普遍的なしきい値や、人間介在そのものによる安全性向上は仮定しない。」
• EA · EA-512AIメモリの削除伝播を検証するAIメモリの削除は、削除APIが成功した時点では完了と判定できません。元データ、会話要約、埋め込み、索引、検索キャッシュ、複製、バックアップへ対象がどこまで伝播したかを調べ、各保存面の削除状態と検証証拠を対応させる必要があります。読取時の不在、物理領域の回収、バックアップの失効は別の証明です。本項は削除要求から復元後の再照合までの運用を扱います。埋め込み残留の詳細はEA-513、訂正後の再計算はEA-514に接続します。
• EA · EA-515共有AIメモリのテナント分離共有AIメモリでは、利用者・チーム・顧客の識別子を保存するだけでは分離が成立しません。認証された主体から許可する範囲を決定し、読取、書込、更新、削除、要約、検索、キャッシュ、復元まで同じ範囲を適用する必要があります。検索だけにフィルタを付けても、別の経路で他テナントの記憶が更新・合成されれば分離は破れます。本項は共有メモリの権限伝播と運用検証を扱い、削除はEA-512、訂正収束はEA-514に接続します。
• EA · EA-518コンテキストの出所ラベルと指示・データの境界コンテキストには、現在の指示、利用者の入力、検索文書、toolの結果、過去の記憶、agentが作った要約など、異なる出所と役割の情報が混在します。出所ラベルはそれらを区別して追跡するために使います。ただし、本文中に「信頼済み」「system」「正本」と書いてあることは権限の証明ではありません。出所、生成・変換の履歴、現在の権限、鮮度、実際のprompt配置を分け、重要な操作の許可を参照データの記述だけから決定しない必要があります。
• EA · EA-520Effective Instruction Contract Envelope「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instruction
• EA · EA-529共有端末で前の利用者のAI会話と権限を引き継がせない店舗や倉庫の端末を交代で利用する場合、前の人をログアウトさせるだけでは、AIの会話・メモリ・添付資料・接続先権限の分離を保証できません。認証状態、画面と端末内データ、サーバーの会話、実行中の処理をまとめて利用者の境界へ結び付ける必要があります。次の利用者へ端末を渡す前に、残留情報の表示と旧権限での操作を防げたことを確認します。
• EA · EA-735本番トレースを評価データセットへ戻すフィードバックループ「本番traceは評価データセットの有力な入力であり、versioned datasetへ昇格して回帰評価へ戻せる。ただし代表性、PII、redaction、version混在、rare-event欠落をcontrolし、trace-derived setだけを完全な品質保証とみなさない。」
• EA · EA-737Differential Privacyで評価テレメトリを保護するAIシステムの評価telemetryには、失敗率、拒否率、品質指標、ツール実行結果、エラー分類、利用パターンなど、運用改善に必要な情報が含まれます。一方、評価対象が実ユーザーの入力や希少な失敗事例に由来する場合、識別子を削除するだけでは個人・組織・機密事象の推定可能性を十分に抑えられないことがあります。Differential Privacy（DP）は、個々のレコードや寄与の有無によって公開統計がどの程度変わり得るかを数学的に制約し、集
• EA · EA-745Privacy-preserving synthetic evaluation data「synthetic dataなので個人情報を含まず安全」とは表現しません。安全な表現は、「synthetic evaluation dataは元データの直接配布を減らせるが、privacyは自動的には保証されない。utility、memorization/re-identification risk、DP等のformal guaranteeを分離して評価し、用途に応じたprivacy/utility gateを設ける」です。
• EA · EA-753Confidential AI inferenceとremote attestationの信頼境界「remote attestationに成功すればConfidential AI inferenceは安全」とは断定しない。「CPU/GPU/driver/firmware/workload policy等のattestation evidenceをversioned policyで検証し、許可状態に一致した場合だけsecretや暗号化資産をreleaseすることで、機密AI workloadの実行環境に対する信頼境界を強化する」とする
• EA · EA-957RAG削除を「要求送信」で完了扱いしないRAGや検索基盤の削除は、削除APIが成功応答を返したことだけで完了と判定してはいけません。少なくとも「削除要求を受理したこと」「管理面で対象ジョブや資源が消えたこと」「検索・取得面で対象データが再び返らないこと」を別の状態として記録し、必要に応じて派生物や外部保存先も個別に確認します。
• EA · PM-GPT-CORE-02OpenAI / GPT：検索・記憶・出典の対応付けこの文書は、CORE-02のQ-C02-001..004をGPT/OpenAIの現行surfaceへ対応づける。対象はChatGPTのCompany Knowledge／apps with sync／Projects／Memoryと、OpenAI APIのfile search／Retrieval／data controlsである。公開仕様、既存のprovider-neutral研究・local実験、本研究の分析を分離し、公開仕様だけで
• EA · PM-NOTEBOOKLM-CORE-02NotebookLM：検索・記憶・出典の対応付けThis supplement answers only REQ-NLM-20260909-001 and Q-NLM-SCOPE-001..004. Consumer/Workspace Gemini Notebook, Workspace admin controls, Gemini Notebook Enterprise, source ingestion, chat/notes, Studio artifacts and dow