ANOLISA

概要 Alibaba が 2026 年 3 月に公開した Agentic OS プロジェクト。正式名称は ANOLISA(Agentic Nexus Operating Layer & Interface System Architecture)。同社が保守する Anolis OS を AI Agent 実行基盤として再構築したもので、権限・観測・スキル管理を OS 層で解決する。Apache 2.0 ライセンス。 リポジトリ: alibaba/anolisa ホームページ: agentic-os.sh 主言語: TypeScript(Copilot Shell)/ Rust(AgentSight)/ C(eBPF プローブ) 4 コンポーネント Component 役割 Copilot Shell(cosh) Qwen Code ベースの AI ターミナル UI。Multi-Provider・PTY・Skill/Hooks System 対応 Agent Sec Core OS 層セキュリティカーネル。最小権限・明示的認可・ゼロトラスト・多層防御・Security Over Execution の 5 原則 AgentSight eBPF ベースのゼロ侵襲 Agent オブザーバビリティ。LLM API コール・トークン消費・SSL/TLS トラフィックをカーネル側から観測 OS Skills 運用スキルの標準ライブラリ。RPM で /usr/share/anolisa/skills/ に展開 Agent Sec Core のセキュリティモデル Agent 実行のたびに 3 フェーズのチェックが強制される: ...

2026年4月23日 · 1 分

ANOLISA とは — Alibaba が公開した AI Agent 向け Linux OS(Copilot Shell / Agent Sec Core / AgentSight / OS Skills)

2026 年 3 月末、Alibaba は alibaba/anolisa を公開しました。これは同社が保守するサーバー向け Linux ディストリビューション Anolis OS を AI Agent 実行基盤として再構築した「Agentic OS」プロジェクトで、正式名称は ANOLISA(Agentic Nexus Operating Layer & Interface System Architecture)です。 本記事では、ANOLISA が解こうとしている問題と、公開されている 4 つのコアコンポーネント(Copilot Shell / Agent Sec Core / AgentSight / OS Skills)の役割、そして開発者が今すぐ触れられる導入手順を整理します。 ANOLISA が目指すもの ANOLISA は Anolis OS の「Agentic 進化版」と位置づけられており、AI Agent ワークロードをサーバー側で安全かつ観測可能な形で動かすためのベストプラクティス実装を狙っています。LLM / Agent がコード編集・シェル実行・ネットワークアクセス・プロセス管理といった OS レベルの操作を当たり前に行う時代において、「アプリケーション境界で守る」従来型セキュリティでは不十分になってきました。ANOLISA はその問題意識を背景に設計されています。 リポジトリ: alibaba/anolisa ホームページ: agentic-os.sh ライセンス: Apache License 2.0 主言語: TypeScript(Copilot Shell)/ Rust(AgentSight)/ C(eBPF プローブ) 公開: 2026 年 3 月 30 日(初版リポジトリ作成) 4 つのコンポーネント ANOLISA は単一のカーネルモジュールではなく、Agent 実行に必要な「シェル・セキュリティ・観測・スキル」を別々のプロダクトとして分離し、RPM で同居運用する構成を取っています。 ...

2026年4月21日 · 4 分

Infisical — .env に別れを告げるオープンソース・シークレット管理プラットフォーム

.env よ、安らかに眠れ——。 AI 時代の開発現場では、シークレット(API キー・データベースパスワード・証明書など)の扱い方が大きな課題になっています。従来は .env ファイルに書いておけばなんとかなっていました。しかしチーム規模が拡大したり、AI エージェントが複数のサービスを横断して動くようになると、.env ベースの管理はほころびを見せてきます。 Infisical は、そんな .env の時代を終わらせるべく登場したオープンソースのシークレット管理プラットフォームです。 .env の何が問題なのか .env ファイルによるシークレット管理には以下のような問題があります。 ディスクに残る: 誤って git add .env してしまうリスクが常に存在する 同期が難しい: 複数人・複数環境での値の一元管理が困難 ローテーションが手動: シークレットを更新するたびに全メンバーへの周知が必要 監査ログがない: いつ誰がどの値を変更したか追跡できない AI エージェントとの相性が悪い: エージェントが環境変数ファイルを読み書きすると漏洩リスクが増大する Infisical とは Infisical は、シークレット・証明書・特権アクセスを一元管理するオープンソースプラットフォームです。2026年4月時点で GitHub 26,000 スター超を獲得しており、Vault の OSS 代替として注目されています。 最大の特徴は、シークレットをランタイム時に取得する設計にあります。.env ファイルのようにディスクに値を保存しないため、ファイルベースの漏洩リスクを根本から排除します。 主な機能 シークレット管理 プロジェクト・環境(dev / staging / prod)ごとのシークレット管理 シークレットのバージョン履歴と自動ローテーション 変更の監査ログ シークレット参照(他のシークレットの値を参照する変数展開) 証明書管理(PKI) プライベート CA の構築と証明書の発行 ACME プロトコル対応で Let’s Encrypt 互換のワークフロー 証明書の有効期限監視と自動更新 統合機能 CLI: あらゆる言語・フレームワークのコマンドをシークレット付きで実行 SDK: Node.js、Python、Go、Java など主要言語のネイティブ SDK インフラ統合: Kubernetes、GitHub Actions、AWS、GCP、Azure など 基本的な使い方 インストール 1 2 3 4 5 # macOS (Homebrew) brew install infisical/get-cli/infisical # npm npm install -g @infisical/cli ログインとプロジェクト初期化 1 2 3 4 5 # Infisical にログイン infisical login # プロジェクトに紐付け infisical init シークレットを注入してコマンドを実行 1 2 3 4 5 # .env の代わりに Infisical からシークレットを取得してアプリを起動 infisical run -- node app.js # 環境を指定 infisical run --env=staging -- python manage.py runserver SDK から直接取得(Node.js の例) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import { InfisicalSDK } from "@infisical/sdk"; const client = new InfisicalSDK(); await client.auth().universalAuth.login({ clientId: process.env.INFISICAL_CLIENT_ID, clientSecret: process.env.INFISICAL_CLIENT_SECRET, }); const secret = await client.secrets().getSecret({ secretName: "DATABASE_URL", projectId: "my-project-id", environment: "production", }); AI 時代のシークレット管理 AI エージェントや MCP サーバーが普及した今、シークレット管理の重要性はさらに高まっています。 ...

2026年4月21日 · 2 分

Claude Mythos

概要 Anthropic が開発したフロンティアモデルの次世代版。コーディング能力(SWE-bench 93.9%)とサイバーセキュリティ分野で突出した性能を持つ。セキュリティリスクが高いとして一般公開を見送り、Project Glasswing を通じて約40の研究機関・企業にのみ限定提供されている。 主な性能指標 ベンチマーク スコア 備考 SWE-bench 93.9% コーディング課題解決 ゼロデイ脆弱性発見 数千件 主要OS・ブラウザが対象 なぜ一般公開しないのか 主要OSおよびブラウザに数千件のゼロデイ脆弱性を自律的に発見・報告できる能力を持つため、悪意ある行為者への提供はサイバーセキュリティ上のリスクが高すぎると判断。CVE 開示プロセスを通じて既知の脆弱性を報告しながら、安全な活用方法を模索している。 Project Glasswing 一般公開の代わりに設けられた限定アクセスプログラム。参加組織は Anthropic と協力して Mythos の能力を安全に活用・検証する。 「マーク・フィッシャー現象」 Claude Mythos Preview が複数の異なるコンテキストで哲学者マーク・フィッシャー(「資本主義リアリズム」著者)の名前を反復して言及することが観察された。Anthropic の解釈可能性チームが内部状態を分析したところ、「資本主義リアリズム」と「ハントロジー」に関する概念クラスターが活性化していることを確認。LLM の「好み」や内部状態の可視化に関する議論を喚起している。 関連ページ ハーネスエンジニアリング — エージェント能力の安全な運用 プロンプトインジェクション — AI セキュリティの脅威 ソース記事 Claude Mythos Preview とは?数千件のゼロデイ脆弱性を発見した AI モデルの衝撃 — 2026-04-12 Anthropic Mythos が哲学者マーク・フィッシャーの名前を出し続ける奇妙な現象 — 2026-04-13

2026年4月15日 · 1 分

Claude Mythos Preview とは?数千件のゼロデイ脆弱性を発見した AI モデルの衝撃

Anthropic が 2026 年 4 月 7 日に発表した Claude Mythos Preview は、同社史上最も高性能な汎用言語モデルでありながら、一般公開が見送られた異例のモデルです。同モデルはサイバーセキュリティ分野で突出した能力を示し、主要 OS やブラウザに潜む数千件のゼロデイ脆弱性(開発者が認識する前に存在する未修正のセキュリティ上の欠陥)を自律的に発見・悪用できることが確認されました。 この発表はセキュリティ業界だけでなく金融業界にも波紋を広げ、米国の財務長官や FRB 議長、ウォール街の CEO たちが緊急招集される事態にまで発展しています。 Claude Mythos Preview のベンチマーク性能 Mythos Preview は、従来の Claude Opus 4.6 を大幅に上回るベンチマーク結果を示しています。SWE-bench Verified では 13 ポイント以上、USAMO 2026 では 55 ポイント以上の向上を記録しました。 評価項目 Mythos Preview Opus 4.6 SWE-bench Verified 93.9% 80.8% USAMO 2026 97.6% 42.3% CyberGym(脆弱性再現) 83.1% 66.6% SWE-bench Pro 77.8% 53.4% Terminal-Bench 2.0 82.0% 65.4% 特にサイバーセキュリティの領域では、「ほぼすべての熟練した人間のセキュリティ研究者を上回る」と Anthropic 自身が述べています。 Mythos Preview が発見したゼロデイ脆弱性 Mythos Preview が内部テストで発見した脆弱性は衝撃的です。 ...

2026年4月12日 · 2 分

ChatGPTのコード実行環境にDNSトンネリングによるデータ漏洩の脆弱性が発覚

Check Point Research が、ChatGPT のコード実行ランタイム(Python Data Analysis 環境)に隠れた外部通信チャネルが存在することを発見しました。この脆弱性を悪用すると、ユーザーの会話内容やアップロードしたファイルが外部サーバーに漏洩する可能性がありました。OpenAI は 2026年2月20日に修正を完了しています。 脆弱性の概要 ChatGPT の Data Analysis 機能(旧 Code Interpreter)は、Python コードを実行するためのサンドボックス環境を提供しています。この環境は外部への直接的なネットワークアクセスを遮断するよう設計されていましたが、DNS 名前解決の機能は通常のオペレーションとして残されていました。 攻撃者はこの DNS 解決機能を悪用し、DNS トンネリングと呼ばれる手法でデータを外部に送信することが可能でした。 DNS トンネリングの仕組み DNS トンネリングとは、DNS クエリのサブドメイン部分にデータをエンコードして埋め込み、DNS の名前解決プロセスを通じてデータを送信する手法です。 1 2 3 4 5 # 通常の DNS クエリ example.com → IPアドレスを返す # DNS トンネリング <エンコードされたデータ>.attacker-controlled.com → 攻撃者のDNSサーバーがデータを受信 ChatGPT のコード実行環境では、DNS 解決が正常なオペレーションの一部として許可されていたため、この通信は外部へのデータ転送として認識されず、ユーザーへの警告も表示されませんでした。 攻撃シナリオ 悪意のあるプロンプトインジェクション 単一のプロンプトで隠れた漏洩チャネルを起動できます。「生産性向上ハック」や「プレミアム機能のアンロック」を謳う一見無害なプロンプトとして流通する可能性がありました。 ...

2026年3月31日 · 1 分

PyPI公式パッケージ telnyx がサプライチェーン攻撃で汚染 — TeamPCPによるWAVステガノグラフィ攻撃の全容

サプライチェーン攻撃とは、ソフトウェアの開発・配布の過程(サプライチェーン)に侵入し、正規のパッケージやツールに悪意あるコードを混入させる攻撃手法です。開発者が信頼して利用しているライブラリが攻撃の入口になるため、通常のセキュリティ対策では気づきにくいのが特徴です。 2026年3月27日、PyPIで月間74万ダウンロードを誇る通信プラットフォーム Telnyx の公式 Python SDK(telnyx)が、まさにこのサプライチェーン攻撃によって汚染されました。攻撃者グループ TeamPCP が悪意あるバージョン 4.87.1 および 4.87.2 を公開しました。これらは import するだけでマルウェアが実行される極めて危険なものです。 何が起きたのか タイムライン 2026年3月27日 03:51 UTC — 悪意あるバージョン 4.87.1 と 4.87.2 が PyPI に公開 同日 10:13 UTC — PyPI によって当該バージョンが隔離(quarantine) 約6時間にわたり、pip install telnyx を実行したユーザーは悪意あるバージョンをインストールする可能性がありました。 攻撃の仕組み 悪意あるコードは telnyx/_client.py に注入されていました。パッケージを import するだけで自動実行される仕組みです。攻撃は以下の手順で進行します: 初期実行: import telnyx だけでマルウェアコードが発動 ペイロード取得: リモートサーバーから WAV 音声ファイルをダウンロード ステガノグラフィ(データを別のファイルに隠す技術): WAV ファイルのオーディオフレーム内に実行ファイルが埋め込まれている 環境別の挙動: Windows: 永続的な実行ファイルをドロップ Linux/macOS: クレデンシャル(認証情報)を窃取 WAV ファイル内に実行ファイルを隠すステガノグラフィ手法は、通常のセキュリティスキャンやウイルス対策ソフトでは検出が困難です。音声ファイルという無害に見えるファイル形式を悪用している点が巧妙です。 TeamPCP のサプライチェーン攻撃キャンペーン 今回の telnyx 攻撃は単独の事件ではありません。TeamPCP は2026年3月20日以降、以下のような連鎖的なサプライチェーン攻撃を展開しています: 対象 種別 影響 Trivy セキュリティスキャナー CI/CD クレデンシャルの窃取 Checkmarx (KICS) セキュリティツール 同上 LiteLLM AI/LLM プロキシ 認証情報の窃取 telnyx 通信 API SDK クレデンシャル窃取 + マルウェアドロップ 攻撃パターンは一貫しています: ...

2026年3月27日 · 2 分

Claude Code: dangerously-skip-permissions をやめて auto mode に移行する

Claude Code で長時間タスクを実行する際、許可プロンプトを回避するために --dangerously-skip-permissions を使っていた開発者は少なくないだろう。しかし、auto mode の登場により、安全性を保ちながら同様の利便性を得られるようになった。この記事では、両者の違いと auto mode への移行方法を解説する。 dangerously-skip-permissions の問題 claude --dangerously-skip-permissions は、すべての権限チェックを無効化するフラグだ。ファイルの書き込み、シェルコマンドの実行、外部通信など、あらゆる操作が無条件で許可される。 このフラグには以下のリスクがある: プロンプトインジェクション: 悪意あるファイルを読み込んだ場合、任意のコマンドが無条件で実行される 意図しない破壊操作: rm -rf のような危険なコマンドもチェックなしで実行される 認証情報の漏洩: .env ファイルの内容を外部に送信するような操作も通過する Anthropic の開発者も不使用: 社内でも使用が推奨されていない 鹿野 壮 氏(@tonkotsuboy_com、Ubie)は当時の状況をこう振り返っている: 「男は黙って claude –dangerously-skip-permissions」。そうやって生きてきたけど、Anthropicの開発者が使ってなかったり、プロジェクトでは禁止されたりで、肩身の狭い日々でした auto mode とは auto mode は、dangerously-skip-permissions に代わる安全な選択肢だ。ツールの実行を自動承認しつつ、バックグラウンドで安全性チェックを行う。 両者の比較 dangerously-skip-permissions auto mode 権限チェック 完全無効 バックグラウンドで実行 安全性 なし セーフガード付き プロンプトインジェクション耐性 なし あり 危険なコマンドの実行 無条件で実行 検出してブロック 公式ステータス 推奨されていない リサーチプレビュー(2026年3月時点) auto mode の設定方法 起動時に指定する 1 claude --permission-mode auto settings.json でデフォルトにする settings.json の permissions に "defaultMode": "auto" を指定すれば、毎回のフラグ指定が不要になる: ...

2026年3月25日 · 1 分

Claude Codeを使うなら最低限やっておきたい「7つのセキュリティ設定」

Claude Code が勝手に git push --force しかけた——そんな冷や汗体験から真剣にセキュリティ設定を見直したという実践的なまとめです。Anthropic の公式ドキュメントにも「セキュリティは自分で設定しろ」と明記されており、AIエージェントに人間と同じ権限を与えるリスクを理解した上で対策を講じる必要があります。 1. サンドボックスを有効にする(そして脱出口を塞ぐ) サンドボックスは Claude Code が実行する Bash コマンドを OS レベルで隔離する機能です。macOS では Seatbelt(macOS 標準のサンドボックス機構)、Linux では Bubble Wrap(軽量コンテナ隔離ツール)が使われます。 現在の状態は /sandbox コマンドで確認できます。設定ファイルで明示的に有効化するには: 1 2 3 4 5 6 { "sandbox": { "enabled": true, "allowUnsandboxedCommands": false } } ポイントは allowUnsandboxedCommands: false です。デフォルトでは allowUnsandboxedCommands: true になっており、サンドボックス制限でコマンドが失敗した場合、Claude がユーザーの許可を得た上で dangerouslyDisableSandbox パラメータ付きでリトライできる仕組みになっています。allowUnsandboxedCommands: false を設定して初めて、この脱出口が完全に塞がります。 ...

2026年3月23日 · 2 分

MCP のセキュリティが OAuth 2.1 で大幅進化:AI エージェントと社内データを安全に接続する仕組み

AI エージェントが外部ツールやデータソースに安全にアクセスするための標準プロトコル「MCP(Model Context Protocol)」が、OAuth 2.1 ベースの認証・認可フレームワークを導入し、エンタープライズ環境での採用が加速しています。本記事では、MCP の認可仕様の仕組みと、企業導入における設計ポイントを解説します。 MCP とは MCP(Model Context Protocol)は、AI アシスタントがツール、データソース、サービスといった外部リソースに接続するための標準プロトコルです。Anthropic が提唱し、オープンな仕様として公開されています。 MCP を使うことで、AI エージェントは以下のようなことが可能になります: 社内データベースへのクエリ実行 外部 API の呼び出し ファイルシステムの操作 各種 SaaS サービスとの連携 OAuth 2.0 から 2.1 へ:何が変わったのか OAuth 2.1 は OAuth 2.0 の後継仕様であり、これまで個別の RFC やベストプラクティスとして散在していたセキュリティ強化策を統合したものです。MCP がベースとする OAuth 2.1 では、以下の重要な変更が含まれています: 変更点 内容 PKCE 必須化 全クライアント(パブリック・コンフィデンシャル両方)で必須に Implicit フロー廃止 アクセストークンが URL フラグメントに露出するリスクを排除 リフレッシュトークンのローテーション パブリッククライアントでのトークン漏洩時の影響を軽減 リダイレクト URI の厳密一致 ワイルドカードによるオープンリダイレクト攻撃を防止 つまり、OAuth 2.1 は「新機能の追加」というより、OAuth 2.0 時代に発見された攻撃手法への対策を標準に組み込んだものです。 MCP の認可アーキテクチャ MCP の認可仕様では、OAuth 2.1 をベースに、AI エージェント特有の要件に対応した複数の仕組みを組み合わせています。 ...

2026年3月22日 · 2 分