Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【AWS Dogwood入門】手元で動かしてみた

【AWS Dogwood入門】手元で動かしてみた

Avatar for 赤神青空

赤神青空

August 23, 2026

More Decks by 赤神青空

Other Decks in Programming

Transcript

  1. ▪Rust 1.96.1 参照実装のCLI / dogwood 1.0.0 で確認 検証 再生 変換

    生成 validate replay lower schema mcp 今ココ 手元で動かす 構文・型・スキーマを検査する 履歴を流して判定の変化を見る Cedar に落とした姿を見る tools/list からスキーマを作る 3/16
  2. ▪機密を読んだ後のメール送信を禁止する 題材:読んだ後は送るな 既定拒否かつ forbid 優先なので、全許可+例外禁止の2本立てで書けます。 dogwood // 基本すべて許可し、例外だけ禁じる permit (principal,

    action, resource); @id("no_send_after_secret_read") forbid (principal, action == Agent::Action::"SendEmail", resource) when temporal { formerly within 24h Agent::Action::"ReadDocument"::response{ input.doc: "customer-secrets" } }; 今ココ 手元で動かす 4/16
  3. ▪流したのは7イベント。判定が出るのは5行 replay の出力 頭の @ は秒、隣の time point は何番目のイベントかの通し番号です。 console

    $ dogwood replay policy.dw \ --policy-schema schema.cedarschema \ --trace trace.log @0 (time point 0): ALLOW @10 (time point 1): ALLOW [rules: 0] [rules: 0] @20 (time point 2): ALLOW @30 (time point 3): ALLOW [rules: 0] [rules: 0] @40 (time point 4): DENY [rules: 1] 今ココ 手元で動かす 5/16
  4. ▪見よう見まねで書いたら動かなかった trace が最初は通らなかった 記事で見かけた形をそのまま書いても通らず、公式 examples 準拠で2つ足しました。 イベント行に足したもの request_context(input: { ...

    }) を付ける requestId の指定 そこで学んだこと 記事の抜粋は、動くトレースの全体ではない リポジトリの examples が一番正確な仕様書になる dogwood --help の出力は最初に保存しておくとよい 今ココ 手元で動かす 7/16
  5. ▪この言語が中で何をしているか lower すると見える 書いたもの(Dogwood) 実際に評価されるもの(Cedar) forbid(..., action == "SendEmail", ...)

    when temporal { lower forbid(..., action == "SendEmail", ...) when { formerly within 24h ... context.policy_1__temporal_0 }; }; 時相条件は、ただの真偽値のフィールド1つに置き換わる イベント履歴 request / response / error セッション単位で蓄積される Dogwood がやること 履歴から真偽を計算して context に詰めて渡す Cedar が判定する 評価エンジンは元のまま ALLOW / DENY やっていることは「アプリ側で集計して context に渡す」と同じ。置き場所が移った temporal を含まないポリシーが Cedar と同じ答えになるのも、評価している主体が同じだから 時相条件は Cedar の context フィールド1つに置き換わる 今ココ 手元で動かす 8/16
  6. ▪どの記事にも書かれていない挙動 連番が何を指すか temporal 節を持つポリシーを2本書いて lower すると、こうなりました。 dogwood @id("rule_a") forbid( ...

    ) when { context.policy_0__temporal_0 }; @id("rule_b") forbid( ... ) when { context.policy_1__temporal_0 }; 命名規則そのものは公式には未確認。「lower するとこうなる」までが言えること 今ココ 手元で動かす 9/16
  7. ▪「できなかったこと」が可能になったわけではない 移ったのは置き場所 Cedar でも、履歴を自前で集計して context に渡せば判定自体はできた。 これまで 記録・集計・相関をアプリに作り込 む これから

    言語と実行基盤の側が引き受ける 効いてくるのは 条件分岐がレビューできる形になる こと 埋もれていたガードレールを、監査できるポリシーとして切り出せます。 今ココ 手元で動かす 10/16
  8. ▪validate演算子は全部通った だけを順に流した結果 OK OK OK NG NG プリミティブ3つ 標準マクロ4つ 生のMFOTL

    AWS記事の生MFOTL eventResource 今ココ 手元で動かす formerly / previous / since count / distinct / sum / bind examples 準拠の形式なら通る そのままではパースエラー AgentCore 専用のフィールド 11/16
  9. ▪参照実装とマネージドで、書ける範囲が違う 通るものと通らないもの ◯ 参照実装で通る プリミティブ3つと標準マクロ4つ examples 準拠の生MFOTL schema mcp のスキーマ

    素のCedar条件との混在 ✕ AgentCore 側の書式 eventResource フィールド AWSの記事のままの生MFOTL AgentCore::Action:: の名前空間 7つの型は手元では動かない 記事のコードを写して動かないとき、まず疑うのはどちら向けの例か。 今ココ 手元で動かす 12/16
  10. ▪同じ流れで、読み取りの結末だけを変えた error は response ではない 成功 失敗 無害 含意 読み取りが

    response 読み取りが error 公開文書を読んだだけ DENY と error は別物 今ココ 手元で動かす 後続の送信は DENY 後続の送信は ALLOW 後続の送信は ALLOW DENY は request に付く判定 13/16
  11. ▪実サーバーなし。JSON MCPマニフェストから 1つで一周できた 生成 検証 再生 含意 schema mcp validate

    replay 手前で試せる 今ココ 手元で動かす Drupe::Action::"print_label" ができた そのまま通った 3回まで ALLOW、4回目で DENY ツール定義があれば書き始められる 15/16
  12. ▪この回の持ち帰り まとめ 01 AWSアカウントは要らない cargo build して CLI を叩くだけで、判定の変化まで見られます。 02

    lower すると正体が見える 時相条件は Cedar の context フィールド1つに置き換わっていました。 03 参照実装とマネージドは書式が違う eventResource など、AgentCore 側にしかない記法があります。 今ココ おわりに 16/16