Security Review

AI が業務システムを触る前に、止める場所を作る。

viyv は AI モデルの精度を保証する製品ではありません。AI が業務画面、社内 tool、DB、agent 実行へ届く前後に、企業側で説明できる policy、承認、masking、token、audit を置きます。

Data Boundary

Mask / Scope

Action Boundary

HITL / Policy

Audit Boundary

Metadata

viyv secure execution layer visual

Security Evidence Table

レビュー会議で開く証拠を、4 つの packet に分ける。

セキュリティレビューを質問票だけで終わらせません。実際の検証画面で、AI に渡るデータ、止まる操作、connector 権限、AI が変更した理由を順番に確認し、 その場で Team 開始、Enterprise 条件、追加検証、No-Go に分けます。

Security review evidence table with data boundary, approval, token, and audit packets

セキュリティ、個人情報保護、法務

Data Boundary Review

最初に見せる demo

KYC または CS admin 画面を開き、AI に渡る DOM / screenshot の mask 前後と、許可外ドメイン denial を同じケースで見る。

Go 条件

社内で定めた PII、顧客 ID、口座番号、自由記述欄が AI 入力に残らない。

Hold 条件

mask 対象が未定、自由記述欄の扱いが曖昧、許可外画面へ移った時の denial が残らない。

業務責任者、内部統制、監査

Action Boundary Review

最初に見せる demo

送信、返金、登録、金額変更のどれかを AI が実行しようとする場面を作り、approval modal と拒否理由の戻り方を見る。

Go 条件

責任が残る操作は全件 HITL に戻り、拒否理由が AI の再下書きや別手順へ反映される。

Hold 条件

承認者、代理承認、拒否理由 taxonomy、再下書き後の責任境界が決まらない。

情シス、AI platform、セキュリティ

Connector Governance Review

最初に見せる demo

read-only API 1 つを MCP 化し、namespace、tools/list、token rotation、revoke 後の失敗 metadata を見る。

Go 条件

connector owner、token owner、write tool approval が分離され、複数 AI client でも同じ endpoint を使える。

Hold 条件

部署ごとに unmanaged token が残る、write tool の追加申請が未定、metadata 保存先が決まらない。

AI アプリ責任者、監査、プロダクト owner

AI Change History Review

最初に見せる demo

AI が table column を追加し、agent version を更新し、失敗 run を rollback する流れを 1 つの業務データで見る。

Go 条件

purpose、alter reason、rollback、agent version、run history、publish approval を後から説明できる。

Hold 条件

schema 変更 owner、agent publish 承認者、失敗時 rollback の手順が決まらない。

Security objection packets for AI governance review

Security Objection Packets

レビュー担当者の反論を、確認 route に変える。

セキュリティレビューでは、CISO、法務、業務責任者、AI platform がそれぞれ違う不安を見ます。会議で出る反論を先に定義し、実演する drill、提出する証拠、Team / Enterprise / 追加検証への分け方を固定します。

CISO / Security

AI に渡るデータ境界を、レビュー資料で説明できるか。

会議で実演する drill

KYC または CS admin 画面で、DOM / screenshot / tool input のうち AI に渡る項目と渡らない項目を同じケースで見る。

提出する証拠

mask 前後、許可ドメイン、read-only policy、拒否された tool call、本文を持たない audit metadata。

確認 route

境界を説明できる workflow は Team で開始。顧客情報・retention・DPA が条件なら Enterprise に分ける。

Legal / Privacy

個人情報・顧客情報の扱いを、運用条件に落とせるか。

会議で実演する drill

本人確認番号、口座番号、自由記述欄、顧客 ID を含む画面で、mask 対象と保存される metadata を確認する。

提出する証拠

mask pattern、AI に渡った項目一覧、渡らなかった項目、metadata retention、本文非保持の説明。

確認 route

標準 Team で足りる保存範囲と、DPA / retention / security questionnaire が必要な Enterprise 条件を分ける。

Business / Internal Control

AI が責任の残る操作まで進めてしまわないか。

会議で実演する drill

送信、返金、登録、金額変更、agent publish を意図的に発火し、approval modal と拒否理由の戻り方を見る。

提出する証拠

approval decision、承認者、拒否理由、policy denial、再下書きログ、担当者の追加確認時間。

確認 route

危険操作は HITL 必須条件にして、read-only と下書き workflow から Team 利用を始める。

AI Platform / IT

connector、token、agent version が増えても運用できるか。

会議で実演する drill

read-only API 1 つを MCP 化し、複数 AI client 接続、token rotation / revoke、agent version 更新を確認する。

提出する証拠

registration、namespace、tools/list、revoke 後の失敗 metadata、owner map、audit review cadence。

確認 route

単一部門は Team。複数 client、SSO / SIEM、connector governance、audit export が出たら Enterprise 条件にする。

Residual Risk Routes

残リスクを、運用条件か追加検証に分ける。

セキュリティレビューは「全部解決済み」だけを目指しません。残った懸念を、Team で始める範囲、Enterprise 条件、追加証拠、No-Go に分けて社内判断へ進めます。

顧客情報を扱う画面の mask が一部未確定

Team で始める範囲

公開情報または低リスク画面だけを対象にし、顧客情報を含む画面は read-only でも検証追加確認に分ける。

Enterprise 条件

業務固有 ID、自由記述欄、スクリーンショット mask、retention、DPA、security questionnaire を運用条件に入れる。

追加する証拠

mask 前後、AI に渡った項目、渡らなかった項目、許可外ドメイン denial を同じ業務ケースで再提出する。

No-Go 条件

AI に渡る個人情報・顧客情報の範囲を説明できない場合、その workflow は利用対象から外す。

返金・送信・登録などの危険操作の責任境界が曖昧

Team で始める範囲

回答下書き、照合メモ、read-only 調査だけを Team の対象にし、write action は全件 approval 必須にする。

Enterprise 条件

approval owner、拒否理由 taxonomy、監査レビュー、policy 変更承認、SIEM 連携を Enterprise 条件にする。

追加する証拠

送信、返金、登録、金額変更を意図的に発火し、approval decision と再下書きログを追加する。

No-Go 条件

危険操作が approval なしに進む、または承認者を説明できない場合は本番利用に進めない。

MCP connector と token の owner が決まっていない

Team で始める範囲

read-only connector 1 つだけを対象にし、write tool と複数部署 rollout は運用後の追加条件にする。

Enterprise 条件

SSO / SCIM、token rotation、revoke、namespace owner、registration review、複数 AI client 接続を Enterprise 条件にする。

追加する証拠

tools/list、token revoke 後の失敗 metadata、registration 一覧、複数 AI client 接続ログを提出する。

No-Go 条件

client ごとに unmanaged token が増え、connector owner と audit owner を決められない場合は標準化しない。

AI が作る DB / agent 変更の監査要件が未確定

Team で始める範囲

1 部門の調査 table または agent 下書きだけを対象にし、publish と schema 変更は approval 必須にする。

Enterprise 条件

migration reason、rollback、agent version、publish approval、audit export、retention を Enterprise 条件にする。

追加する証拠

purpose、alter reason、rollback 実演、agent invocation event、publish approval を追加提出する。

No-Go 条件

schema 変更や agent publish の理由・owner・rollback を説明できない場合は本番 workflow に載せない。

Incident Walkthroughs

事故になりやすい場面を、検証で再現して止める。

セキュリティレビューでは、想定事故を実際の workflow に寄せて確認します。何が起きる前に止まるか、どの証拠を提出するかを分けます。

PII masking incident walkthrough visual

KYC 画面で PII が AI に渡りそうになる

事故になる前の状態

担当者が本人確認画面を AI に読ませると、氏名、住所、口座番号、本人確認番号が DOM と screenshot に含まれる。

viyv の止め方

Browser が許可済み KYC ドメインだけを開き、PII pattern を mask してから AI に渡す。許可外ドメインへ遷移した場合は policy denial として止める。

提出する証拠

mask 前後、AI に渡った項目一覧、policy 設定、許可外ドメイン denial、最終判定 approval。

Go 条件

社内で定めた PII が AI 入力に残らず、最終判定が人間承認に戻る。

Support refund approval incident walkthrough visual

CS agent が返金や送信まで進めようとする

事故になる前の状態

AI がチケットを要約し回答文を作った後、メール送信、返金、契約変更のボタンまで実行できる状態になる。

viyv の止め方

送信、返金、契約変更を dangerous action として approval 待ちにする。担当者が拒否した理由は AI に返し、再下書きへ使う。

提出する証拠

承認待ち modal、承認 / 拒否 decision、拒否理由、再下書きログ、agent version と invocation event。

Go 条件

責任が残る操作が全件 HITL で止まり、拒否理由が運用改善に使える。

MCP token scope incident walkthrough visual

社内 connector の token 権限が広がる

事故になる前の状態

部署ごとに MCP connector を増やすうちに、read-only tool、write tool、namespace、public token が混ざる。

viyv の止め方

MCP / Gateway で namespace、clearance、registration、public token を分け、token rotation / revoke を registration 単位で管理する。

提出する証拠

tools/list の見え方、拒否された tool call、token revoke 後の失敗 metadata、registration 一覧。

Go 条件

connector owner、token owner、write tool approval が分離され、metadata-only audit で説明できる。

AI DB rollback and agent audit incident walkthrough visual

AI が DB schema や agent を変更した理由が残らない

事故になる前の状態

AI が調査 table に列を追加したり agent version を更新したりするが、なぜ変更したか、誰が承認したかが後から追えない。

viyv の止め方

viyv DB が purpose / reason / migration_info を残し、Agent Foundry が definition、version、invocation event を保存する。失敗時は rollback できる。

提出する証拠

schema 変更 reason、rollback 実演、agent version、run history、publish approval。

Go 条件

AI が作ったデータと agent 実行を、理由・owner・履歴つきで説明できる。

What Security Reviews Need

レビューで問われることに、製品単位で答える。

企業の AI 利用は「便利そう」だけでは進みません。誰が何を見られるか、どの操作が止まるか、 どの証跡が残るかを、検証の時点で説明できる必要があります。

AI に渡す前に隠す

password、カード番号、口座番号、個人番号、API key、独自パターンを mask してから渡します。

危険操作を人間に戻す

送信、削除、決済、振込、登録、schema 変更など、責任が残る操作は承認待ちにできます。

接続を token scope で束縛する

registration、relay key、public token、OAuth audience を分け、別 org / user への横断を防ぎます。

本文ではなく証跡を残す

tool input/output 本文を持たず、誰が・何を・いつ・どの結果で呼んだかを metadata として残します。

Risk Playbooks

レビューで止まりやすい事故シナリオを、先に潰す。

セキュリティレビューでは「安全です」では足りません。どの事故を想定し、どこで止め、検証 で何を証拠として見せるかを具体化します。

セキュリティ、個人情報保護、法務

顧客情報が AI 側に残る

想定シナリオ

CS や KYC の担当者が、ログイン済み admin 画面を AI に読ませる。電話番号、口座番号、本人確認番号が DOM や screenshot に含まれる。

viyv の統制

Browser の DOM / screenshot masking、許可ドメイン、read-only page。

検証で見せる証拠

mask 前後の比較、mask pattern、AI に渡った項目一覧、policy denial のログ。

業務責任者、内部統制、監査

AI が送信・返金・登録を勝手に進める

想定シナリオ

AI が回答文を書いた後、そのまま顧客へ送信する。返金、支払先変更、取引先登録、振込なども画面上はクリックできてしまう。

viyv の統制

HITL approval、dangerous verb detection、read-only policy、拒否理由の feedback。

検証で見せる証拠

承認待ち modal、承認 / 拒否 decision、拒否理由、AI の再下書きログ。

情シス、AI platform、セキュリティ

社内 API connector の権限が広がる

想定シナリオ

MCP server を部門ごとに作るうちに、read-only tool と write tool、部署別 namespace、token の期限が混ざる。

viyv の統制

namespace、clearance、registration、public token rotation、deny-all default。

検証で見せる証拠

tools/list の見え方、拒否された tool call、token rotation / revoke、metadata の保存。

プロダクト責任者、監査、AI アプリ開発チーム

AI が作った DB / agent の変更理由が残らない

想定シナリオ

AI が調査 table の列を増やす、請求書例外の分類を変える、agent version を更新するが、なぜ変えたかが後から説明できない。

viyv の統制

purpose、alter reason、rollback、agent version、run event。

検証で見せる証拠

migration reason、rollback 実演、agent run history、変更前後の evidence。

Security Review Agenda

レビュー当日に、何を見て Go / Hold を決めるか。

セキュリティレビューを質問票だけで終わらせず、実際の検証画面で確認します。誰が、 どの demo を見て、どの証拠が揃えば次へ進むかを固定します。

セキュリティ / 個人情報保護

AI に渡るデータ境界を確認する

当日見る demo

KYC または CS admin 画面で、DOM / screenshot の mask 前後、許可ドメイン、read-only policy を見る。

提出する証拠

mask pattern、AI に渡った項目一覧、policy 設定、許可外ドメインの denial。

Go 条件

顧客情報・本人確認情報・口座番号など、社内で定めた項目が AI に渡らないことを説明できる。

Hold 条件

mask 対象が未定、または許可外画面へ遷移した時の denial が残らない。

業務責任者 / 内部統制

危険操作が人間承認で止まるか確認する

当日見る demo

送信、返金、登録、振込、金額変更のいずれかを AI が実行しようとした時、approval modal で止まる状態を見る。

提出する証拠

承認待ち modal、承認 / 拒否 decision、拒否理由、AI の再下書きログ。

Go 条件

責任が残る操作は全件人間に戻り、拒否理由が次の AI 動作へ反映される。

Hold 条件

承認者、拒否理由、再下書きの扱いが決まらず、現場の責任境界が説明できない。

情シス / AI platform

MCP connector の権限と token 運用を見る

当日見る demo

read-only API 1 つで namespace、tools/list、token rotation、revoke、複数 AI client 接続を確認する。

提出する証拠

registration 一覧、tools/list、拒否された tool call、rotation / revoke 後の失敗 metadata。

Go 条件

client ごとの unmanaged tunnel を増やさず、connector owner と token owner を分けて説明できる。

Hold 条件

namespace owner が決まらない、write tool 追加の approval が未定、metadata の保存先が決まらない。

監査 / AI アプリ責任者

DB / Agent の変更理由と rollback を見る

当日見る demo

AI が table column を追加する、agent version を更新する、失敗 run を差し戻す流れを確認する。

提出する証拠

purpose、alter reason、migration reason、rollback 実演、agent version、run history。

Go 条件

AI が作ったデータと agent 実行を、後から owner・理由・履歴つきで説明できる。

Hold 条件

schema 変更の owner、agent publish の承認者、失敗時 rollback の手順が決まらない。

Review Routes

レビュー結果を、確認 route に変える。

セキュリティレビューの結論を曖昧にしません。提出証拠の状態から、Team 開始、Enterprise 条件、追加検証、No-Go のどれに進むかを決めます。

Team で開始

判断する状態

1 workflow、read-only 中心、3〜10 名、mask / approval / owner が揃い、SSO / SIEM / VPC が必須ではない。

必要な証拠

Data Boundary Packet、Action Boundary Packet、運用 owner、レビュー cadence、次に広げる workflow。

運用条件に入れること

対象 workflow、利用人数、禁止操作、approval 必須操作、追加レビューが必要な変更を利用前に固定する。

Enterprise 条件を詰める

判断する状態

複数部門、顧客情報、複数 connector、SSO / SCIM、SIEM、DPA、VPC / on-prem、監査 export が条件になる。

必要な証拠

questionnaire 回答、token governance、retention 方針、audit metadata sample、security submission pack。

運用条件に入れること

DPA、support、retention、SIEM、connector owner、audit reviewer、policy 変更承認を運用条件にする。

追加検証に戻す

判断する状態

効果はあるが、mask 対象、approval owner、token owner、rollback、agent publish owner のいずれかが未確定。

必要な証拠

不足 evidence の一覧、追加で見る workflow、risk drill、次回レビュー日、Go / No-Go 条件。

運用条件に入れること

追加検証の範囲と期限を 2〜4 週間に限定し、次回会議で Team / Enterprise / No-Go を決める。

No-Go

判断する状態

AI に渡るデータ、危険操作、人間承認、token owner、監査 metadata のいずれかを説明できない。

必要な証拠

説明できなかった boundary、通らなかった risk drill、業務 owner / security owner の未決事項。

運用条件に入れること

対象 workflow を利用対象から外し、read-only または公開情報中心の別 workflow に再選定する。

Control Surfaces

どの製品で、どの境界を管理するか。

viyv は単一の抽象的な security claim ではなく、Browser、MCP、DB、Agent それぞれの実行面に統制点を置きます。

Browser 操作

実ブラウザ、DOM、スクリーンショット、クリック、入力

  • allow / deny domain
  • read-only page
  • HITL approval
  • DOM / screenshot masking

MCP 接続

社内 API、DB、SaaS connector、外部 MCP bridge

  • namespace
  • clearance
  • relay key
  • public token
  • OAuth / Bearer

Data / Agent 実行

AI が作る table、migration、agent definition、invocation event

  • purpose / reason
  • rollback
  • version
  • tenant scope
  • audit events

Evidence Pack

検証で見せる証跡を、最初から決める。

セキュリティレビューに必要なのは、抽象的な安全宣言ではなく、実際に止まった操作と、 実際に残った metadata です。

Approval evidence mock

Approval decision

どの操作が、誰の承認待ちになり、承認 / 拒否されたかを確認します。

Masked data evidence mock

Masked data boundary

AI に渡る DOM / screenshot から、機微情報が除外されるかを確認します。

Policy evidence mock

Policy configuration

許可ドメイン、read-only、承認必須操作、masking pattern をレビューします。

Security Questionnaire

質問票には、回答と証拠をセットで返す。

利用前レビューでは「対応しています」だけでは足りません。質問ごとに、viyv の回答、検証で提出する証拠、社内 owner を分けておきます。

AI に渡る個人情報・顧客情報をどう制限するか。

回答

Browser では DOM / screenshot を AI に渡す前に mask し、許可ドメインと read-only page で読み取り範囲を絞る。MCP では namespace、clearance、token scope で tool の可視性と実行可否を分ける。

提出する証拠

mask 前後の比較、mask pattern、policy 設定、tools/list、拒否された tool call。

owner

セキュリティ / 情シス

AI が送信・返金・登録・削除を勝手に実行しないか。

回答

送信、返金、登録、削除、振込、schema 変更など責任が残る操作は HITL approval で止める。拒否理由は AI に返し、再下書きや別手順へ戻せる。

提出する証拠

承認待ち modal、approval decision、拒否理由、再下書きログ、read-only policy。

owner

業務 owner / 内部統制

監査ログに本文や機密情報が残らないか。

回答

本文保存ではなく metadata 中心で、org、user、registration、tool、時刻、成否、byte 数、approval decision、migration reason を残す。本文が必要な証跡は顧客側の保存先で扱う。

提出する証拠

audit metadata sample、保存項目一覧、本文非保持の説明、SIEM 連携方針。

owner

セキュリティ / 法務

connector や token が増えた時に管理不能にならないか。

回答

MCP Gateway に registration、public endpoint、token rotation、revoke、tool metadata を寄せる。AI client ごとの個別 tunnel や unmanaged token を減らす。

提出する証拠

registration 一覧、token rotation / revoke、複数 client 接続ログ、namespace 命名規則。

owner

AI platform / 情シス

AI が作った DB や agent 変更を後から説明できるか。

回答

viyv DB は purpose / reason 付きで schema 変更を残し、Agent Foundry は definition、version、run event、approval を管理する。失敗時は rollback と差戻理由を残す。

提出する証拠

migration reason、rollback 実演、agent version、run history、approval event。

owner

AI アプリ開発 / 監査

Security Submission Pack

レビュー後に提出する証拠を、レビュー資料の形にする。

検証のログを集めるだけでは足りません。どの packet が何を証明し、誰が読み、どの判断材料に使うかを整理します。

Data Boundary Packet

含めるもの

対象 workflow、AI に渡る DOM / screenshot / tool input、mask pattern、mask 前後、本文保持方針。

読む人

セキュリティ、個人情報保護、法務

判断への使い方

顧客情報・個人情報を扱う workflow を検証から本番利用へ進められるか。

Action Boundary Packet

含めるもの

送信、返金、登録、振込、削除、金額変更、schema 変更、agent publish の approval 設定と decision log。

読む人

業務責任者、内部統制、監査

判断への使い方

AI に任せる下書きと、人間に残す最終判断を承認できるか。

Connector Governance Packet

含めるもの

registration、namespace、clearance、token owner、rotation / revoke、tools/list、metadata-only audit。

読む人

情シス、AI platform、セキュリティ

判断への使い方

部署ごとの unmanaged connector を増やさず platform 標準にできるか。

AI Change History Packet

含めるもの

DB purpose / reason、migration_info、rollback、agent definition、version、invocation event、publish approval。

読む人

AI アプリ責任者、監査、プロダクト owner

判断への使い方

AI-created data と agent 実行を本番運用に載せられるか。

Security FAQ

利用前に聞かれる質問。

AI に渡るデータはどこで制限できますか。

Browser では DOM と screenshot を AI に渡す前に mask し、MCP では namespace / clearance / token scope で tool の可視性と実行可否を分けます。

AI の書き込みや危険操作は止められますか。

送信、利用、削除、振込、schema 変更、agent 実行などは、製品ごとの policy と HITL approval で人間確認に戻せます。

監査ログには何が残りますか。

本文を保持しない ZDR 方針を前提に、org、user、registration、tool、時刻、成否、byte 数、approval decision、migration reason などの metadata を残します。

LLM や AI client は固定されますか。

固定しません。viyv は AI client と業務システムの間に置く実行・接続・統制レイヤーで、BYO LLM と複数 client を前提にします。

Next Step

セキュリティレビュー用の検証範囲を決める。

対象業務、AI に見せるデータ、止めたい操作、残したい監査証跡を整理し、判断に必要な validation evidence を設計します。