AtlaSent MCP Server

@atlasent/mcp-server

あらゆる MCP 互換 AI エージェントに対し、実行前の認可を必須にする MCP サーバーです。

AtlaSent AI Action Protection への開発者向けエントリーポイントです。エンタープライズチームはデザインパートナープログラムを通じて導入しています。

AtlaSent は、人、ソフトウェア、AI による重大なアクションのための、セキュリティと組織的権限のインフラストラクチャです。

この MCP サーバーにより、AI エージェント（Claude、Cursor、Windsurf、あらゆる MCP ホスト）で利用できます。エージェントのツール呼び出しが実システム（本番環境へのデプロイ、データのエクスポート、アクセス権の付与など）を変更する前に、エージェントはまず AtlaSent に確認します。API キーを使うリモートモードでは、次のように動作します。

1. 数行の設定で、エージェントに接続します。
2. リスクの高いアクションは、人による承認を待ちます。それ以外は通常どおり実行されます。
3. 承認に基づいて決定された場合、誰が承認したかも含め、すべての決定に署名付きの記録が残ります。

アカウント不要で、60 秒でお試しいただけます：npx -y @atlasent/mcp-server（ローカルモード。何も保護しないデモです）。

無料、アカウント不要： MCP サーバーのツール一覧をAI Permission Checkに貼り付けると、実システムを変更できるツールと、承認すべき人を確認できます。ブラウザー上で動作します。

ローカルでのブロックは無料です。 アカウントなしで自分のマシン上のアクションを実際にブロックするには、MCP GateまたはClaude Code agent guardをお使いください。どちらも無料の Community プランに含まれています。ホスト型の判定、共有ポリシー、チーム向けの承認機能はAtlaSent のプランでご利用いただけます。

エンジニア向け

AtlaSent は実行時認可を行います。特定の重大なアクションが現時点で認可されているかを判定し、allow の場合は範囲を限定した Permit を発行します。その Permit を実行ゲートで検証し、その後にのみ、対象となるネイティブな効果を許可します。

もっともらしいリクエストは、組織の権限を示すものではありません。

この MCP サーバーは、AtlaSent の認可プリミティブを Model Context Protocol ホストに公開し、処理順序を最初から最後まで実証する、保護されたデプロイデモも含んでいます。

誰が決定したのか？

このリポジトリには2つのパッケージがあり、そのうち1つには2つのモードがあります。3つすべてがツール呼び出しをブロックします。証拠となるのは3つのうち1つだけで、その違いは機能一覧ではなく、誰が承認したかです。

サーフェス	決定した人	内容
@atlasent/mcp-server ローカルモード	組み込みのヒューリスティック	何でもありません — 認証情報不要のデモです。最終的なルールは allow で、認識できないアクションの種類も許可します。保護手段として決して頼らないでください。
@atlasent/mcp-gate + policy.json	事前に、編集可能なファイルで決めるあなた	運用者の設定です。 {"default":"deny","rules":[]} で開始し、ルールを記述するまで、すべてをブロックします。アカウントもネットワークも不要で動作します。
@atlasent/mcp-gate クラウドモード	実行時に決めるあなたの組織	組織による許可 — 1回限りで、その呼び出しに紐づけられ、後から検証できます。

誰にも気づかれずに編集できるルールは設定です。組織が発行し、1回だけ消費され、後から提示できる許可は権限です。どちらも呼び出しを止めますが、*「誰が承認したのか？」*という問いに答えられるのは後者だけです。この問いが生じるのはインシデントの前ではなく、後です。

ゲートは、すべての判定でどちらが決定したかを示します。no_matching_rule はローカルポリシー、cloud_permit_consumed は組織による許可を表します。**これらの理由文字列は、意図的に一般的な「ブロック済み」に正規化されていません。**まとめて扱わないでください。

2つのパッケージは正反対の方向を向いているため、分けられています。mcp-server は AtlaSent を、エージェントが認可を求めるために呼び出す MCP ツールとして公開します。mcp-gate は他者の MCP サーバーの前に配置され、呼び出しをインターセプトします。

不変条件

保護対象のパスが強制される場合：

Action proposed
  → current organizational Authority + Policy + Context evaluated
  → Decision
      deny / hold / escalate → STOP
      allow → bounded Permit
  → Permit Verification at the execution Gate
      invalid / expired / replayed / mismatched / error → STOP
      verified → native effect may execute
  → execution/native-effect Evidence recorded where the integration supplies it

評価は実行ではありません。肯定的な Decision は Gate ではありません。保護対象の副作用が発生する前に Permit Verification が行われます。

クイックスタート：アカウント不要で60秒

このサーバーを試すのに、AtlaSent アカウントや API キーは必要ありません。認証情報を設定せずに実行すると、オフラインで動作するプロセス内ルールエンジンであるローカルモードで起動します。

ワンクリックでインストール（ローカルモード、アカウント不要）：

MCP ホストの設定に以下を追加してください（Claude Desktop、Claude Code、Cursor、Windsurf、VS Code など。ホストごとのファイルの場所は以下を参照してください）。

{
  "mcpServers": {
    "atlasent": {
      "command": "npx",
      "args": ["-y", "@atlasent/mcp-server"],
      "env": { "ATLASENT_MODE": "local" }
    }
  }
}

次に、エージェントに 「billing-api を本番環境にデプロイして」 と頼んでください。承認がないため、組み込みルールによって拒否されます。承認を付けて再度頼むと許可され、サーバーが許可証を検証してから、シミュレーションされたデプロイが実行されます。

組み込みのローカルルール（src/localEngine.ts）：

状況	判定
承認のない本番環境での操作	deny
変更時間外の破壊的操作（delete、drop、purge など）	hold
署名／認定／付与／取り消し／一時停止／再開の操作	deny
上書き／リリース／エクスポート／インポート／公開の操作	hold
ルールを通過した操作	allow → 1回限りの許可証、TTLは5分

ローカルの許可証には署名がないため、ローカルモードは開発、CI、試験用途向けです。本番環境での強制を担うものではありません。NODE_ENV=production の場合、サーバーはローカルモードへのフォールバックを拒否します。署名付き許可証、監査証跡、組織独自のポリシーが必要になったら、リモートモードに切り替えてください — API キーを取得してください。

ソースから実行

git clone https://github.com/AtlaSent/atlasent-mcp-server.git
cd atlasent-mcp-server
npm install
npm run build
npm run demo      # blocked deploy → approved + verified deploy → replay refused, fully offline

Docker で実行

docker build -t atlasent-mcp .
docker run -i --rm atlasent-mcp                                          # local mode, stdio
docker run -i --rm -e ATLASENT_API_KEY -e ATLASENT_BASE_URL atlasent-mcp  # remote mode

Claude Code プラグイン：エージェントによる本番環境の破壊を防止

packages/agent-hooks は Claude Code プラグインです。破壊的なコマンドやリリースのコマンドは、人の確認を待ちます。DROP TABLE、terraform destroy、ボリュームの削除、git push --force、本番環境へのデプロイなどが対象です。確認する人がいない場合、これらは拒否されます。それ以外は通常どおり実行されます。ローカルで動作し、アカウントは不要です。

/plugin marketplace add AtlaSent/atlasent-mcp-server
/plugin install atlasent-guard@atlasent

「キーボードの前にいる人が承認した」は、ここまでです。このリポジトリの残りは組織向けの仕組みです。組織が指名した承認者と、後から証明できる許可証を提供します。

Canon に基づくアクション

AtlaSent は、場当たり的なツール文字列をすべて、新しい管理対象のアクションタイプとして扱うわけではありません。

安定したアクション ID には、Protected Action Canon を使用してください。重要な例を2つ示します。

production.deploy
agent.tool.invoke

汎用的な AI ツール呼び出しには、公開 Canon に基づくアクションタイプとして agent.tool.invoke を使用し、ツール固有の情報（ツール名、対象、環境、引数／ペイロードのダイジェスト、リソースの状態、その他必要なコンテキスト）は、選択した統合経路でサポートされる認可コンテキストまたはバインディングフィールドに含めてください。

独自の分類体系を作るのではなく、読み取り専用の atlasent_lookup_action ツールを使用して、Canon に基づくアクションタイプを調べてください。

権限は承認ではありません

以下の概念は分けて考えてください。

• 権限 — ある種類の変更を実行するための、範囲が定められた組織上の継続的な権利です。
• 認可 — 今この時点で、この特定のアクションを実行してよいかをリクエストごとに判断することです。
• ポリシー — 判断に適用される、バージョン管理された条件です。
• 承認 — ポリシー条件を満たす場合がある、検証済みの入力です。継続的な権限でも、最終的な認可結果でもありません。
• 判断 — プラットフォーム境界における allow | deny | hold | escalate です。
• 許可証 — 範囲が限定された、肯定的な認可を示す成果物です。
• 検証 — 実行境界で、許可証と適用されるバインディングを確認することです。
• 実行／ネイティブな効果 — 基盤となるツールまたはシステムが実際に行うことです。
• エビデンス／証明 — 認可と、観測された場合は効果／結果を示す、永続的な証拠です。

人間による承認、好ましいリスクシグナル、ポリシーへの一致、デプロイチケット、ワークフローのステータスは、それだけで組織上の権限になることはありません。

保護されたツールのデモ

deploy_service は意図的にシンプルにしています。2 層の保護された経路を示します。

agent requests deploy_service
  → authorize internal agent-tool compatibility gate
  → verify outer Permit
  → authorize production.deploy
  → verify production.deploy Permit
  → simulated deployment effect

内部の外側ゲートでは、Canon に基づく agent.tool.invoke アクション（CANON-000026 / ACT-0029）を使用します。これは、AtlaSent エコシステム全体で、標準的な汎用 AI エージェントのツール呼び出しとして文書化されているものと同じ公開識別子です。以前は、レガシーの未カタログ化 ID model.agent.execute_tool を使用していましたが、ランタイムに対応する action_classes のプロビジョニング経路がありませんでした（どのシード／マイグレーションでも、このスラッグを持つ行は作成されません）。そのため、実際の変更されていない Atlasent 組織では、ツール固有の内側ゲートの判断に関係なく、外側ゲートは常に NO_ACTION_CLASS による拒否を返すしかありませんでした。外側ゲートを agent.tool.invoke に移行することで、この目的のためにすでに存在する、ランタイムの「AI Agent Safeguard」プロビジョニング経路を利用できるようになります。詳しい調査と判断の記録については、AtlaSent/atlasent-mcp-server#121 をご覧ください。

いずれかの判断が allow 以外の場合、またはいずれかの許可証の検証に失敗した場合、デプロイ結果は生成されません。

保護されたツールのレスポンスには、シミュレートされたネイティブ結果とともに、アクション固有の検証結果が含まれます。

{
  "decision": "allow",
  "permit_token": "...",
  "verification": {
    "outcome": "verified",
    "valid": true
  },
  "result": {
    "status": "deployed",
    "service": "billing-api"
  }
}

返された許可証は、実行境界での検証ですでに使用済みです。再度検証することは、デプロイ後に必要な手順ではなく、リプレイとして扱ってください。

ヒューマン・イン・ザ・ループのデモ：保留、承認、実行、記録

examples/hitl-demo.mjs は、ホスト型ランタイムと実際の GitHub リポジトリを使用した、一連の中断のない処理を示します。atlasent_governed_file_change（AI Action Protection、デザインパートナープログラム）を使用します。

段階	表示される内容
1 ATTEMPT	エージェントが設定ファイルの変更を要求します
2 HOLD	ランタイムが処理を保留し、approval_request_id を返します。ファイルを再読み込みしますが、変更されていません
3 BOUND	内容を変えて同じリクエストを送ると拒否され、承認の対象がこの変更だけであることが確認されます
4 APPROVE	担当者が AtlaSent コンソールの「Approvals」でリクエストを承認します
5 EXECUTE	境界で許可を検証した後、書き込みが正確に1回実行され、コミット SHA が出力されます
6 RECORD	ツールがコミット時点とブランチの先端で変更結果を再読み込みし、デモでもう一度読み込んだ後、ai_action_proof.v1 のハッシュが出力されます

キーはエージェントに紐付ける必要があります（コンソール：「Settings」→「Connect an AI agent」）。デモ専用のリポジトリを使用してください。

npm run build
ATLASENT_API_KEY=ask_test_... \
ATLASENT_BASE_URL=https://<ref>.supabase.co/functions/v1 \
ATLASENT_ENVIRONMENT=staging \
ATLASENT_AI_ACTION_GITHUB_REPO=owner/demo-repo \
ATLASENT_AI_ACTION_GITHUB_BRANCH=main \
ATLASENT_AI_ACTION_GITHUB_TOKEN=<token that can write only that repo> \
npm run demo:hitl

デモで出力されるのは、ツールが返した内容またはリポジトリに表示された内容だけです。いずれかの段階が実行されなかった場合、デモは FAIL at <stage> で停止し、終了コード 1 を返します。たとえば、組織の agent.tool.invoke ポリシーで担当者の関与なしに変更が許可される場合、保留をスキップするのではなく、ATTEMPT の段階でデモが失敗します。組織のポリシーでは、ヒューマン承認を必須にする必要があります。デモは hitl-demo-evidence-<ts>.json に記録し、許可は sha256 としてのみ記録します。

実演の前に、npm run demo:hitl:preflight を実行してください。これは読み取り専用のセットアップ確認です。GET リクエストのみを送信し、リクエスト、承認、許可、コミットは作成しません。前提条件、コンソールでの操作、想定される出力を記載した発表者向け実行手順書は、docs/DEMO_90_SECONDS.md です。

npm run demo:hitl -- --simulate は、インメモリのランタイム、リポジトリ、承認者を使って、同じ段階をオフラインでリハーサルします。出力されるすべての行は [SIMULATED] で始まり、実際のネットワーク呼び出しは拒否されます。シミュレーション実行をライブ実行として発表しないでください。

自己ゲート型エージェントのパターン

独自のネイティブツール境界を管理するエージェントまたは MCP ホストには、次の安全なパターンがあります。

const decision = await evaluate({
  action_type: "agent.tool.invoke",
  actor_id: "agent:research-bot",
  environment: "production",
});

if (decision.decision !== "allow") {
  throw new Error("Action is not authorized");
}

const verification = await verify_permit({
  permit_token: decision.permit_token,
  action_type: "agent.tool.invoke",
  actor_id: "agent:research-bot",
  environment: "production",
  // Present target_id / payload_hash when the selected authorization path
  // binds those fields.
});

if (!verification.valid) {
  throw new Error("Permit did not verify");
}

// Only now may the protected native effect occur.
const result = await runProtectedTool();

ラッパー、デコレーター、プロンプト、MCP ツールの定義が、自動的にバイパス不可能な Gate になるわけではありません。強制力があるという主張は、実際のトポロジーに基づく必要があります。つまり、必要な認可と許可の検証が成功しない限り、保護対象として主張する経路からネイティブな効果に到達できない必要があります。

コアツール

evaluate

MCP ホスト向けのシンプルなローカル／リモート認可ヘルパーです。

Input:  { action_type, actor_id, environment, approvals?, change_window?, target_id?, change_plan?, target_system? }
Output: { decision: "allow" | "deny" | "hold", permit_token?, notes?, ... }

allow が返されても、まだ実行しないでください。まず実行境界で許可を verify_permit に渡してください。

verify_permit

実行境界での検証ヘルパーです。

Input: {
  permit_token,
  action_type,
  actor_id,
  environment,
  approvals?,
  change_window?,
  target_id?,
  payload_hash?
}
Output: { outcome: "verified" | "expired" | "invalid" | "error", valid, ... }

valid === true の場合にのみ続行してください。正常に検証されると、その契約が適用される場合は、単一使用の許可が消費されます。

deploy_service

保護されたデプロイのデモです。シミュレートされたデプロイ結果を生成する前に、必要な認可と検証を内部で実行します。

atlasent_evaluate / atlasent_verify_permit

ホスト型 V1 API 向けのツールです。小さな evaluate デモ用エンベロープを超える追加コンテキストが必要な場合は、より詳細なリモート評価パスを使用してください。検証は引き続き実行境界で行います。

atlasent_verify_permit は POST /v1/permits/verify を呼び出しますが、ホスト型 API ではこのエンドポイントを提供していないため、セルフホスト型ゲートウェイに対してのみ登録されます（ホスト型ツールとセルフホスト型ツールを参照）。ホスト型 API に対しては、verify_permit で検証してください。

agent.tool.invoke などの agent.* アクションでは、atlasent_evaluate は evaluate と同様に評価前にソースの来歴を封印します。結果には bound_payload_hash と bound_actor_id が含まれる場合があります。許可はこれらの値に紐付けられるため、payload_hash と actor_id として verify_permit に渡してください。

atlasent_lookup_action

Action Type、ゲートフラグ、認可パターン、証拠要件、グラフの関係を読み取り専用で Canon から検索します。

Input:  { slug? }    // exact Canon slug, e.g. "production.deploy"
        { query? }   // plain language, e.g. "deploy the api service to prod"
        {}           // list the full Canon
Output: { found, result_count, actions[], retrieval? }

query は、ベンダー提供の Canon を対象とする決定論的な完全オフラインのランカーで解決されます（埋め込みサービスもネットワークも不要です — src/actionRetrieval.ts）。レスポンスには retrieval ブロックが含まれます。

retrieval.confidence	意味
confident	Canon のエントリが明確に 1 つ一致しています。actions[0] がそのエントリです。そのまま実行しても安全です。
ambiguous	2 つ以上のエントリが近いか、リクエストが部分的にしか一致していません。retrieval.candidates を読んで選ぶか、表現を変えてください。
none	Canon に、この説明に一致するアクションはありません。found は false、actions は空で、hint は Canon の取り込みパイプラインを示します。

このツールが Action Type を捏造することはありません。候補はすべて参照によって Canon のエントリに対応しており、Canon で回答できないリクエストは、もっともらしい slug を返すのではなく none を返します。emergency、weekend、urgent などのコンテキスト語は、異なるアクションを示す証拠ではなく、ポリシーのコンテキストとして扱われます。LIFECYCLE.md の分類原則に従い、「本番環境への緊急デプロイ」も production.deploy に解決されます。

atlasent_atlas_lookup

Authority、Policy、Decision、Permit、Verification、Evidence、Gate、Trust Root など、AtlaSent の標準概念を読み取り専用で検索します。

atlasent_evidence_gap_report

「ガバナンスされていないデプロイはどこですか？」.github/workflows/*.yml ファイルのテキストを渡すと、実際のシステムを変更するすべてのステップ（デプロイ、パッケージやイメージの公開、データベースのマイグレーション、terraform／pulumi の apply）が、それぞれ次のステータスとともに返されます。

status	意味
bound	ジョブ内で先行してゲートが実行され、そのステップは if: steps.<gate>.outputs.verified == 'true' の場合にのみ実行されます。
gated	ジョブ内で先行してゲートが実行されます。拒否された場合、ステップの実行前にジョブが失敗します。
gated_upstream	ゲートは、このジョブが needs: で指定するジョブ内にあります。ステップが実行される場所では、Permit の再検証は行われません。
weak	ゲートは存在しますが、ステップを停止できません。たとえば、continue-on-error、ゲート自体の if:（skip_gate 入力など）、または Permit を使用するものがない mode: evaluate-only です。
ungoverned	ゲートがありません。

Input:  { workflows: [{ path, content }], gate_actions? }
Output: { summary, findings[], triggers, parse_errors[], not_checked[], next_step, setup? }

すべてのギャップ（ungoverned または weak）には fix が付属します。ギャップの前に挿入する atlasent-action ステップ（適切な Action Type：production.deploy、package.release、infrastructure.change）、ステップをゲートで検証済みの Permit に紐付ける正確な if:、既存のゲートに必要な変更（continue-on-error の削除、skip_gate 条件の削除、id-token: write の追加）が含まれます。ギャップがある場合、setup にゲートが必要とする API キーのサインアップリンクが表示されます。修正を適用してレポートを再実行すると、ステップは bound と表示されます。

ローカルモードで動作します。API キーもネットワークも不要で、何も実行されません。gate_actions では、独自のゲートラッパー（たとえば複合アクション）を指定できます。これらは、内部が検査されていないカスタムゲートとして報告されます。レポートには、常に確認できない内容（リポジトリの設定、CI 外のデプロイ、./deploy.sh の内部）が記載されます。また、解析できないファイルはスキップされず、parse_errors に記載されます。問題のないレポートであっても、ガバナンスされていないものがないことの証明にはなりません。

atlasent-exposure-scan（1つのコマンドで、共有可能なレポートを作成）

実際のチェックアウトに対して同じレビューを実行し、開いて共有できるレポートを作成します。

npx -y -p @atlasent/mcp-server@latest atlasent-exposure-scan path/to/repo
# writes atlasent-exposure-review.html, .md, .json and .csv

@latestを付けたままにしてください。付けないと、npxが該当コマンドを含まない古いキャッシュ済みコピーを再利用することがあります（Windowsではその場合、"'atlasent-exposure-scan' is not recognized"と表示されます）。オフラインで動作し、.github/workflows/を読み取るだけで、ネットワークへのアクセスはありません。HTMLは単一の自己完結型ファイルです（スクリプトや外部アセットはありません）。レビューの冒頭には「まずこれらを修正」と表示されます。問題点は根本原因ごとにまとめられ、本番環境への影響を優先し（環境が特定できない場合は安全と見なしません）、何が問題を引き起こすか、どのシークレットを読み取れるかに基づいて順位付けされます。.csvにはこの順序でステップごとに1行が含まれ、スプレッドシートやチケットへのインポートに使えます。CIチェックとして使うには--fail-on-gapsを追加し、ファイルの出力先を指定するには--out <dir>を使います。独自のラッパーアクション（またはatlasent-action内のuses: ./）でゲートを設定する場合は、--gate-action <uses>（複数回指定可能）で名前を指定すると、そのステップはゲート済みとして扱われます。ワークフローファイルを読み取れない場合や解析できない場合、レポートにはINCOMPLETE SCANと読み取れなかったファイルが表示され、コマンドは終了コード3で終了します。

atlasent-change-sample（変更管理のサンプル検査で判明すること）

変更管理を監査する担当者は、本番環境への変更をサンプル抽出し、それぞれがマージされたコードそのものに対して、作成者以外の人物によって承認されたかどうかを確認します。このコマンドは、1つのリポジトリのマージ済みプルリクエストについて、その確認を行います。

npx -y -p @atlasent/mcp-server@latest atlasent-change-sample your-org/your-repo --days 90
# writes atlasent-change-sample.html, .md and .json

GitHubのAPIを通じて、プルリクエスト、レビュー、およびマージされた各コミット上のチェック実行結果を、あなたのトークン（GH_TOKEN、GITHUB_TOKEN、またはgh auth token）で読み取ります。GitHubのみを呼び出します。AtlaSentに何も送信されず、トークンが表示されたり書き込まれたりすることもありません。レポートの冒頭には、「マージされた112件の変更のうち7件は変更管理のサンプル検査に不合格となる可能性があります」のような1行が表示され、不合格となる変更すべてがプルリクエストにリンクされています。

• ボットによる承認は人間による承認ではありません。また、レビュー担当者が後から「変更を要求」したりレビューを却下したりすると、それ以前の承認は取り消されます。
• 以前のコミットに対する承認は、マージされたコミットを誰かが承認している場合にのみ有効です。
• 読み取れなかったものは失敗ではなく、不明として扱われます。レポートにはINCOMPLETE SCANと表示され、終了コード3で終了します。
• GitHub外での承認、プルリクエストを経由せずに行われた変更、実際にデプロイされた内容、ブランチ保護のバイパス権限、レビュー担当者があなたのポリシーに基づいて承認権限を持っていたかどうかは確認できません。レポートにはその旨が記載されます。

--base <branch>でブランチを指定します（デフォルトはリポジトリのデフォルトブランチです）。--fail-on-findingsを指定すると、変更が1件でも不合格となる場合に終了コード1で終了します。これはコンプライアンス評価でも認証でもありません。

atlasent_exposure_review

無料のAuthorization Exposure Reviewです。atlasent_evidence_gap_reportと同じオフライン分析を実行し、人が読めるレビューとして結果を返します。スキャン対象と確認できない内容、ゲートによって停止できないまま実システムを変更できるすべてのステップ、それぞれの具体的な修正方法、およびすでにゲートされている内容を示します。

Input:  { workflows: [{ path, content }], gate_actions? }
Output: { review: "exposure_review.v1", markdown, summary, help?, sign_up_url? }

markdownはそのまま表示してください。渡されたファイルのみを対象とし、組織の認可態勢を評価するものではないことが明記されています。問題点がある場合、または何も認識されなかった場合、helpにはリクエストページへの任意のリンクが2つ表示されます。1つは独立した実装アドバイザーに調査結果の説明を依頼するため、もう1つはゲートの導入支援を依頼するためのものです。そのページで依頼し、同意した場合に限り、あなたの情報がアドバイザーと共有されます。AtlaSentはアドバイザーの作業から手数料を受け取りません。

APIキー不要、ネットワーク接続なし、何も実行されません。

atlasent_integrity_audit

組織の Authority グラフに内部不整合がないかを読み取り専用で監査します。ホステッドモード専用です。組織は API キーからサーバー側で特定されます。

Input:  { decision_window_days? }   // 1-3650; omit to let the server choose
Output: the integrity report, verbatim

これは合否を判定するヘルスチェックではなく、このツールが独自の判定を追加することもありません。 各指摘には、3 種類の classification が付与されます。

classification	解釈
defect	Authority グラフに実際の不整合があります。
non_exercisable	多くの場合、正しく健全な状態です。たとえば、期限切れであるべき許可が期限切れになっている場合です。失敗ではありません。
unresolved	命題を検証できませんでした。決して問題なしと見なさないでください。「確認できなかった」ことと「確認して何も見つからなかった」ことは別の事実です。

findings リストが空の場合でも、結論を出す前に summary.audited_scope を確認してください。判断対象となる期間が短いからといって、指摘がないとは限りません。監査を完了できない場合、サーバーは部分的なレポートを返さず、リクエストを拒否します。このツールは、その状態を空のレポートではなくエラーとして返します。

atlasent_get_permit / atlasent_check_permit / atlasent_get_decision

単一のレコードを読み取り専用で参照します。現時点では、セルフホストの /v1/* ゲートウェイ専用です。ホステッド API には登録されていません（ホステッドツールとセルフホストツールを参照）。atlasent_get_permit と atlasent_check_permit は、atlasent-api#4522 が本番環境に反映された後、ホステッド API でも利用できるようになります。

atlasent_get_permit    { permit_id }                     -> the permit record (status, actor, action, times, decision_id)
atlasent_check_permit  { permit_id }                     -> { valid, status: active|revoked|consumed|expired, revoked_at? }
atlasent_get_decision  { evaluation_id, include_trace? } -> { evaluation, trace?: { approvals, permit_uses, webhooks } }

atlasent_check_permit は許可を消費せずにステータスを読み取ります。保留中のアクションを実行する前に使用し、失効していないか確認してください。ただし、これは認可ではありません。実行するのは verify_permit の後に限ってください。atlasent_get_decision には audit:read スコープが必要です。許可の decision_id が、渡す ID です。

許可ツールは、許可の token（ベアラー認証情報）や signature を返しません。ツールが返す情報はすべてエージェントのコンテキストとトランスクリプトに含まれるため、両フィールドは API による除去に加え、クライアント側でも除去されます。

サーバーは、ポリシー、許可、承認、エビデンス、コンプライアンス、VQP の各ツールも公開します。登録されるツールは、ホステッド API とセルフホストのゲートウェイのどちらを対象とするかによって異なります（ホステッドツールとセルフホストツールを参照）。構成における正確なツール一覧は、MCP の tools/list を使用して確認してください。

プロンプト

サーバーは、MCP のプロンプトも公開します。ホストで選択して、実行前に認可を行うフローを開始するためのテンプレートです。

プロンプト	引数	エージェントへの指示
gate-action	action、environment（任意）	atlasent_lookup_action で Canon のアクションタイプを検索し、evaluate を呼び出します。判定が allow でなければ停止し、アクションの実行直前に verify_permit を呼び出してから、アクションを実行します。
explain-decision	decision（判定 JSON）	アクションが許可、拒否、保留された理由と、結果が変わる可能性のある要因を、回避策を提案せずに平易な言葉で説明します。
find-action-type	description	atlasent_lookup_action で平易な説明を解決し、スラッグを作り出さずに confident / ambiguous / none を処理します。

プロンプトはエージェントを誘導するだけです。ゲートではないため、エージェントは無視できます。アクションが保護されるのは、実行直前に許可が検証される場合に限られます（不変条件を参照）。

承認ワークフロー

承認を必須にできますが、承認を解決することは、保護対象のアクションを実行することと同じではありません。

Approval / Assertion collected
  → current Authorization / reevaluation path
  → Decision
  → Permit on allow
  → Verification
  → native effect

承認するのは AtlaSent コンソール上の人であり、エージェントではありません。このサーバーには、承認を作成または解決するツールが意図的に用意されていません。アクションが人による判断待ちになると、結果に approval_request_id が含まれます。これを指定して atlasent_await_approval を呼び出すと、人がコンソールで判断する間、待機できます。承認された場合は許可証が返されますが、引き続き verify_permit による検証が必要です。拒否、期限切れ、またはタイムアウトの場合は許可証が返されず、アクションは実行されません。（リモートモードのみ。ローカルモードでは承認は行われません。）保護対象のアクションは、続行前に現在の認可経路と実行境界の検証を引き続き満たす必要があります。

変更計画と計画の変更。 production.deploy、infrastructure.change、production.rollback、secret.configuration.change には change_plan（{ operation, revision?, artifact_ref? }。revision と artifact ref の少なくとも一方が必要です）が必要です。これを deploy_service、evaluate、または atlasent_evaluate に渡してください。サーバーはまず、計画を正確に記録した変更概要を作成し、その概要 ID と同じ計画を使って評価します。キーで概要を作成できない場合（HTTP 403）、またはランタイムに概要がない場合（HTTP 404）、サーバーは計画だけを使って評価し、notes エントリーを追加します。それ以外の概要作成エラーが発生した場合、評価は中止されます。権限を取得する際、サーバーは同じ計画を再提示するため、不一致があれば計画が実際に変更されたことを意味します。待機中に計画が変更された場合は、新しい計画を change_plan として atlasent_await_approval に渡してください。デフォルトでは、サーバーは新しい計画について、元の承認を指定する supersedes_approval_id を設定した、リンク付きの再申請を1 件作成し、人の判断を待ちます。結果の summary には手順が表示されます。たとえば、「計画が X から Y に変更 → 再申請を送信（承認 …）→ 待機中 → 承認済み」のようになります。on_plan_mismatch: "use_approved" を指定すると、サーバーは承認済みの計画の権限を取得し、それを approved_plan として返します。その計画をそのまま実行してください。2 回目の不一致、取り消し済みまたは疑わしい承認、あるいは auto_rerequest_on_mismatch: false の組織ポリシーがある場合、許可証を返さずに待機を終了します。結果には差分と次に行うべきことが含まれます。

検証済みのアクターを必要とするアクションクラスでは、ランタイムは承認を approved_awaiting_claim に解決し、取得リクエストでアクターの本人性が提示された場合にのみ許可証を発行します。次にサーバーは、独自のエージェント向けに短時間有効な actor_identity.v1 をランタイムに要求します（POST /v1-agent-actor-identity。登録済みエージェントに紐付いた API キーでのみ利用可能）。アクションの種類と環境は承認レコードから取得され、サーバーは { actor_identity } を指定して取得します。その本人性を取得できない場合、権限は取得されず、許可証も返されません。このエンドポイントのないランタイム（HTTP 404）では、サーバーは従来どおり空の本文で取得し、結果に注記を追加します。

どのエージェントか、誰のエージェントか、どのチャットか

すべての評価呼び出しでは、どのアプリからのものか（MCP クライアントの名前。例：claude-code、cursor）と、agent_session としてどのチャットまたはセッションからのものかが報告されます。AtlaSent はこれをエージェントホストからの報告としてラベル付きで保存します。アクションの原因となった会話を追跡するのに役立ちますが、判断には使用されません。

• セッション ID：Streamable HTTP セッション。ない場合は、ホストが設定していれば ATLASENT_SESSION_ID。それもない場合は、mcp-process- を接頭辞とするプロセスごとの ID。
• 実行またはジョブ ID として、ATLASENT_RUN_ID を任意で指定できます。
• エージェント API キーを使う場合、actor_id は空のままにしてください。AtlaSent はキー自体からエージェントと、そのエージェントが代理する人を識別するため、モデルが自分の名前を指定することはありません。

実行の証拠

atlasent_record_execution_evaluation は、ネイティブな効果が発生した後に、観測された実行結果を記録します。この証拠機能は、実行前の Permit 検証に代わるものではありません。セルフホスト型の /v1/* ゲートウェイに対してのみ登録されます（ホスト型ツールとセルフホスト型ツールを参照）。

以下の記述は区別してください。

• allow Decision は、肯定的な認可判断が行われたことを証明します。
• 検証済み Permit は、その時点で、範囲が限定された認可アーティファクトが Gate のチェックに合格したことを証明します。
• 実行／ネイティブ効果の証拠は、基盤となるアクションが実際に発生したという主張を裏付けるものです。

ローカルモードとリモートモード

モード	目的
local	設定不要：オフラインで動作するインプロセスのルールエンジン、署名なしの Permit。開発、デモ、CI 向けです。
remote	設定済みの AtlaSent ホスト型／ランタイム API を呼び出します。

API キーを取得する

1. 無料アカウントを console.atlasent.io/auth/sign-up で作成します。
2. AI エージェントを接続（設定 → API キーからも選択できます）を選びます。エージェントに名前を付け、アプリ（Claude Code、Claude Desktop、Cursor、Windsurf など）を選択すると、コンソールにキーと、貼り付ける正確なコマンドまたは JSON が表示されます。
3. MCP ホストの設定に貼り付けます。ATLASENT_API_KEY だけでサーバーはリモートモードに切り替わります。ATLASENT_BASE_URL は任意で、デフォルトではホスト型 API が使用されます。
4. エージェントに、重大な影響を伴う操作（たとえば「API サービスを本番環境にデプロイして」）を試すよう依頼します。コンソールに判断が表示され、承認が必要な操作は、誰かが承認するまで承認キューで保留されます。

リモートモードでは、ローカルモードでは利用できない機能が使えます。Ed25519 署名付きの使い捨て Permit、組織独自のポリシー、改ざんを検知できる監査証跡です。

リモートの例：

ATLASENT_API_KEY=ask_live_xxx \
ATLASENT_BASE_URL=https://api.atlasent.io/functions/v1 \
ATLASENT_MCP_READONLY=1 \
npx @atlasent/mcp-server

ATLASENT_BASE_URL のデフォルトは https://api.atlasent.io/functions/v1 です。ホスト型 API で動作するすべての呼び出しは、このベース URL 配下のデプロイ名の関数に送信されます。/v1-evaluate、/v1-verify-permit、/v1-approvals/...、/v1-authority-intelligence/...、および REST スタイルのツールは以下のとおりです。

ツール	リクエスト
atlasent_list_policies	GET {base}/v1-policies/
atlasent_list_permits	GET {base}/v1-permits
atlasent_list_audit_events	GET {base}/v1-audit/events（エンドポイントにそのフィルターがないため、evaluation_id は受け付けません）
atlasent_get_evidence_export	GET {base}/v1-evidence-exports/{id}

組織は常に API キーから決定されます。org_id 引数で別の組織を選択することはできません。

ホスト型ツールとセルフホスト型ツール

一部のツールは引き続き、ドメインルートでスラッシュ形式の /v1/<resource> パスを呼び出します（サーバーはこれらのパスから /functions/v1 を取り除きます）。しかし、api.atlasent.io はこの形式を提供していないため、これらのリクエストは 404 を返します。エージェントに動作するツールだけを表示するため、サーバーがホスト型 API を対象にしている場合、これらのツールは登録されません：

グループ	ツール
ポリシー	atlasent_get_policy, atlasent_create_policy, atlasent_update_policy, atlasent_delete_policy
許可証	atlasent_get_permit, atlasent_check_permit, atlasent_revoke_permit, atlasent_permit（発行）, atlasent_verify_permit（v1 検証）
判断とエビデンス	atlasent_get_decision, atlasent_record_execution_evaluation
Webhook	atlasent_create_webhook, atlasent_delete_webhook
SCIM	atlasent_list_scim_users, atlasent_get_scim_user, atlasent_create_scim_user, atlasent_patch_scim_user, atlasent_delete_scim_user, atlasent_list_scim_groups
SIEM	atlasent_get_siem_config, atlasent_upsert_siem_config, atlasent_test_siem_delivery
エビデンスのエクスポート	atlasent_list_evidence_exports, atlasent_create_evidence_export
VQP レポート	atlasent_vqp_audit_summary, atlasent_vqp_drift_events

「ホスト型 API を対象にする」とは、ATLASENT_BASE_URL が未設定または空欄（デフォルト）、解析不能、あるいは api.atlasent.io または AtlaSent のホスト型 Supabase プロジェクトのいずれかであることを意味します。ローカルモードでもこれらのツールは非表示になります。ローカルエンジンを使用せず、リモート呼び出しのみを行うため、ローカルモードではいずれも動作しません。

次のいずれかの場合は、変更されずに登録されます。

• サーバーがリモートモードで、ATLASENT_BASE_URL が別のホスト（独自の /v1/* ゲートウェイを実行するセルフホスト型ランタイム）を指している、または
• ATLASENT_MCP_ENABLE_GATEWAY_TOOLS=1（または true）が設定されている（対象を問わない）。

各ツールは、デプロイ先のパスをルーティングするランタイムハンドラー、そのパス（まだ存在しません）、または異なるリクエスト形式や認証情報が必要な状態です。理由は src/engine.ts の呼び出し箇所に記載されています。atlasent_get_permit と atlasent_check_permit は、atlasent-api#4522 が本番環境に反映されれば、ホスト型 API で動作するようになります。非表示化によって変更されるのは tools/list のみです。evaluate、verify_permit、atlasent_evaluate、deploy_service、承認待ちは常に登録され、どちらの場合も同じように動作します。ATLASENT_MCP_READONLY=1 が設定されている場合、登録されたツールのうち変更を伴うものは引き続き削除されます。

ATLASENT_FUNCTION_REGION は、ランタイムのエッジ関数を実行する場所を制御します。未設定の場合、ホスト型ランタイムへの呼び出しは、データベースに近い us-west-1 で実行されます。セルフホスト型のベース URL では、Supabase の最寄りリージョンのデフォルトが適用されます。別のリージョンに固定するにはリージョン ID を設定し、固定を無効にするには auto を設定します。データベースの近くで実行することは重要です。evaluate は、データベースへの逐次的なラウンドトリップを数十回行います。

ライブデモ用の読み取り専用モード

次を設定してください：

ATLASENT_MCP_READONLY=1

ライブ API のデモ中に、変更を伴う管理ツールが登録されないようにします。読み取り専用モードによって、サーバーがあらゆる脅威に対応するセキュリティ境界になるわけではありません。公開される変更機能の範囲を縮小します。保護された実行パスは、上記の Authorization と Verification の構成に引き続き依存します。

フェイルクローズの動作

AtlaSent Authorization と Permit Verification を必須とするよう設定されたパスでは、次の条件をブロック条件として扱います。

• Decision が allow ではない
• 必須の Permit がない
• 認証または API のエラー
• Permit が無効、期限切れ、取り消し済み、リプレイ済み、またはバインディングが不一致
• Verification エラー
• 必須の実行バインディングがない

シャドー評価やアドバイザリー評価は状況の把握に役立ちますが、実行保護が適用されている状態とは異なります。

Claude Desktop

claude_desktop_config.json に追加します。リモート、ローカル、HTTP の各設定を含むすぐに使えるファイルは、examples/claude_desktop_config.json にあります。

{
  "mcpServers": {
    "atlasent": {
      "command": "npx",
      "args": ["-y", "@atlasent/mcp-server"],
      "env": {
        "ATLASENT_MODE": "remote",
        "ATLASENT_API_KEY": "ask_live_xxxxxxxxxxxxxxxx",
        "ATLASENT_BASE_URL": "https://api.atlasent.io/functions/v1",
        "ATLASENT_MCP_READONLY": "1"
      }
    }
  }
}

Claude Code

claude mcp add でサーバーを追加します。stdio 経由で実行されます。-- 以降は、Claude Code が起動するコマンドです：

claude mcp add atlasent -e ATLASENT_MODE=local -- npx -y @atlasent/mcp-server

claude mcp list を実行して接続を確認するか、Claude Code のセッション内で /mcp を実行すると、使用できるツールを確認できます。

スコープ。 --scope（-s）で、エントリの保存先を指定します：

スコープ	保存先	用途
local（デフォルト）	現在のプロジェクトのみを対象とするユーザー設定	試しに使う
project	リポジトリのルートにある .mcp.json（チェックイン済み）	リポジトリで作業する全員とサーバーを共有する。Claude Code はプロジェクトサーバーを起動する前に、各ユーザーに承認を求めます。
user	すべてのプロジェクトを対象とするユーザー設定	Claude Code を実行するすべての場所で使う

claude mcp add atlasent --scope project -e ATLASENT_MODE=local -- npx -y @atlasent/mcp-server

は、次の .mcp.json を書き込みます：

{
  "mcpServers": {
    "atlasent": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@atlasent/mcp-server"],
      "env": { "ATLASENT_MODE": "local" }
    }
  }
}

プロジェクトスコープの .mcp.json に API キーをコミットしないでください。リモートモードでは、local または user スコープを使用してください。

リモートモード。 ATLASENT_API_KEY を設定します。キーを設定するとサーバーはリモートモードに切り替わり、ATLASENT_BASE_URL のデフォルト値は https://api.atlasent.io/functions/v1 になります。ATLASENT_MODE=remote を設定すると、リモートモードを明示できます。ATLASENT_MODE=local を設定すると、キーが設定されていてもローカルモードが強制されます。ローカルモードとリモートモードを参照してください。

claude mcp add atlasent --scope user \
  -e ATLASENT_MODE=remote \
  -e ATLASENT_API_KEY=ask_live_xxxxxxxxxxxxxxxx \
  -e ATLASENT_BASE_URL=https://api.atlasent.io/functions/v1 \
  -- npx -y @atlasent/mcp-server

モードを切り替えるには、claude mcp remove atlasent でエントリを削除してから、もう一度追加します。

Cursor

プロジェクト用の .cursor/mcp.json またはグローバル設定の ~/.cursor/mcp.json に追加します。コピーしてそのまま使えるローカルモード用ファイルです。アカウントは必要ありません：examples/cursor_mcp.json。

{
  "mcpServers": {
    "atlasent": {
      "command": "npx",
      "args": ["-y", "@atlasent/mcp-server"],
      "env": {
        "ATLASENT_MODE": "remote",
        "ATLASENT_API_KEY": "ask_live_xxxxxxxxxxxxxxxx",
        "ATLASENT_BASE_URL": "https://api.atlasent.io/functions/v1",
        "ATLASENT_MCP_READONLY": "1"
      }
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json に追加します。コピーしてそのまま使えるローカルモード用ファイルです。アカウントは必要ありません：examples/windsurf_mcp_config.json。

{
  "mcpServers": {
    "atlasent": {
      "command": "npx",
      "args": ["-y", "@atlasent/mcp-server"],
      "env": {
        "ATLASENT_MODE": "remote",
        "ATLASENT_API_KEY": "ask_live_xxxxxxxxxxxxxxxx",
        "ATLASENT_BASE_URL": "https://api.atlasent.io/functions/v1",
        "ATLASENT_MCP_READONLY": "1"
      }
    }
  }
}

VS Code

ワークスペースの .vscode/mcp.json に追加します。VS Code のトップレベルキーは mcpServers ではなく servers です。コピーしてそのまま使えるローカルモード用ファイルです。アカウントは必要ありません：examples/vscode_mcp.json。

{
  "servers": {
    "atlasent": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@atlasent/mcp-server"],
      "env": { "ATLASENT_MODE": "local" }
    }
  }
}

リモートモードでは、env ブロックをCursorのセクションに示されているものに置き換えます。

その他の MCP クライアント

同じサーバーは、通常の MCP サーバー設定方法（command: npx、args: ["-y", "@atlasent/mcp-server"]、および上記と同じ env ブロック）を使って、ほかの MCP 互換ホストでも設定できます。

このサーバーは Glama（このリポジトリの Dockerfile からビルドされ、掲載情報の所有権は glama.json に記載）と、公式 MCP Registry（io.github.Atlasent/mcp-server、マニフェストは server.json）にも登録されています。そのため、レジストリに対応したホストでは、手書きの設定ブロックなしでこのサーバーを検出してインストールできます。npm run bundle を実行すると、同サーバーの MCPB バンドルがビルドされ、バンドルからインストールするホストで利用できます。掲載されている場所と掲載されていない場所については、docs/DISTRIBUTION.md を参照してください。

開発

npm install
npm run typecheck
npm run lint      # ESLint (toolchain in tools/lint, installed on first run)
npm test          # offline: no network, no API key
npm run build
npm run demo

npm test は完全にオフラインで実行されます。ローカルモードのテストではネットワークに接続せず、リモートモードのテストでは fetch をモックします。外側のエージェントツールの Permit またはアクション固有のデプロイ用 Permit のいずれかで Verification に失敗した場合、保護対象のデプロイデモがネイティブな結果を生成しないことを証明する回帰テストが含まれています。

すぐ使える環境をお求めですか？リポジトリを開発コンテナー（VS Code または GitHub Codespaces）で開くと、作成時にインストールとビルドが実行されます。

コミュニティ

• 質問やアイデア： GitHub Discussions
• バグや小規模な機能： issue を作成
• 大規模な変更（新しいツール、ワイヤー形式、またはフェイルクローズ動作）：まず RFC issue を作成してください
• 貢献をご希望ですか？ CONTRIBUTING.md を読み、good first issue を探してください
• セキュリティに関する報告： [email protected] にメールしてください。SECURITY.md を参照してください。公開 issue は作成しないでください。

参加者は全員、行動規範に従うことが求められます。

セキュリティ

API キー、署名情報、顧客の秘密情報、本番環境の認証情報をソース管理に含めないでください。認可コンテキストは、選択したポリシーとバインディングに必要な情報に限定してください。

セキュリティに関わるインテグレーションでは、制御フローにおいて、必要な認可および検証チェックの後に実際の副作用を実行してください。判定をログに記録した後に処理を続行しても、強制にはなりません。

関連する公開コンポーネント

• atlasent-sdk — 言語 SDK
• atlasent-action — GitHub Actions インテグレーション
• atlasent-verify — オフライン証拠検証ツール
• atlasent-keys — 公開検証情報

ライセンス

Apache License, Version 2.0 の下でライセンスされています。