AtlaSent MCP Server

@atlasent/mcp-server

MCP server that enforces authorize-before-execute for any MCP-compatible AI agent.

It is the developer entry point to AtlaSent AI Action Protection, which Enterprise teams adopt through a design partner program.

AtlaSent is security and organizational authority infrastructure for consequential actions by people, software, and AI.

This MCP server brings it to AI agents (Claude, Cursor, Windsurf, any MCP host). Before an agent's tool call changes a real system (a production deploy, a data export, an access grant), the agent asks AtlaSent first. With an API key (remote mode):

1. Connect it to your agent with a few lines of config.
2. Risky actions wait for a person to approve them. Everything else runs as normal.
3. Every decision gets a signed record, including who approved it when the decision relied on an approval.

Try it in 60 seconds with no account: npx -y @atlasent/mcp-server (local mode, a demo that protects nothing).

Free, no account: paste your MCP server's tool list into AI Permission Check to see which tools could change real systems and who should approve them. It runs in your browser.

Local blocking is free. To actually block on your own machine without an account, use MCP Gate or the Claude Code agent guard. Both are part of the free Community plan. Hosted decisions, shared policies and approvals for a team are on the AtlaSent plans.

For engineers

AtlaSent performs execution-time authorization: determine whether a specific consequential Action is authorized now, issue a bounded Permit on allow, verify that Permit at the execution Gate, and only then allow the governed native effect.

A plausible request is not organizational authority.

This MCP server exposes AtlaSent authorization primitives to Model Context Protocol hosts and includes a protected deployment demo that proves the ordering end to end.

Which authority decided?

This repository ships two packages, and one of them has two modes. All three block tool calls. Only one of the three is evidence, and the difference is not a feature list — it is *who said yes*.

A rule you can silently edit is configuration. A permit your organization issued, that was consumed once and can be produced later, is authority. Both stop the call; only the second answers *"who authorized this?"* — which is the question that arrives after an incident, not before one.

The gate says which one decided, on every decision: no_matching_rule is your local policy, cloud_permit_consumed is an organizational permit. These reason strings are deliberately not normalised into a generic "blocked." Do not collapse them.

The two packages point in opposite directions, which is why they are separate: mcp-server exposes AtlaSent *as* MCP tools an agent calls to ask for authorization; mcp-gate sits *in front of* someone else's MCP server and intercepts.

The invariant

For an enforced protected path:

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

Evaluation is not execution. A positive Decision is not the Gate. Permit Verification happens before the protected side effect.

Quickstart: 60 seconds, no account

You don't need an AtlaSent account or API key to try this server. With no credentials set, it runs in local mode: an in-process rules engine that works offline.

One-click install (local mode, no account):

Add this to your MCP host config (Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, and others; per-host file locations are below):

{

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

Then ask your agent to *"deploy billing-api to production"*. The built-in rules deny it because it has no approvals. Ask again with an approval and it's allowed, and the server verifies the permit before the simulated deploy runs.

Built-in local rules (src/localEngine.ts):

Local permits are unsigned, so local mode is for development, CI, and trying things out. It's not a production enforcement boundary. The server refuses to fall back to local mode under NODE_ENV=production. When you're ready for signed permits, audit evidence, and your organization's own policies, switch to remote mode — get an API key.

Run from source

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

Run with 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 plugin: stop agents destroying production

packages/agent-hooks is a Claude Code plugin. Destructive and shipping commands wait for a person: DROP TABLE, terraform destroy, volume deletes, git push --force, production deploys. With nobody to ask, they are refused. Everything else runs as normal. Local, no account.

/plugin marketplace add AtlaSent/atlasent-mcp-server

/plugin install atlasent-guard@atlasent

"Someone at the keyboard said yes" is where it stops. The rest of this repository is the organizational version: an approver your organization named, and a permit you can prove afterwards.

Canon-backed Actions

AtlaSent does not treat every ad-hoc tool string as a new governed Action Type.

Use the Protected Action Canon for stable Action identity. Two important examples are:

production.deploy

agent.tool.invoke

For a generic AI tool invocation, use agent.tool.invoke as the public Canon-backed Action Type and carry tool-specific facts—tool name, target, environment, arguments/payload digest, resource state, and other required context—in the authorization context or binding fields supported by the selected integration path.

Use the read-only atlasent_lookup_action tool to discover Canon-backed Action Types instead of inventing a parallel taxonomy.

Authority is not Approval

Keep the concepts separate:

• Authority — standing, scoped organizational right to cause a class of change.
• Authorization — per-request determination whether this exact Action may proceed now.
• Policy — versioned conditions applied to the determination.
• Approval — verified input that may satisfy a Policy condition; not standing Authority and not the final Authorization result.
• Decision — allow | deny | hold | escalate at the platform boundary.
• Permit — bounded positive-Authorization artifact.
• Verification — execution-boundary check of the Permit and applicable bindings.
• Execution / native effect — what the underlying tool or system actually does.
• Evidence / Proof — durable evidence of the authorization and, where observed, the effect/result.

A human Approval, favorable risk signal, policy match, deployment ticket, or workflow status does not by itself become organizational Authority.

Protected-tool demo

deploy_service is intentionally small. It demonstrates a two-layer protected path:

agent requests deploy_service

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

The internal outer gate uses the Canon-backed agent.tool.invoke Action (CANON-000026 / ACT-0029) — the same public identifier documented throughout the AtlaSent ecosystem as the canonical generic AI-agent tool invocation. It previously used a legacy, uncatalogued identity, model.agent.execute_tool, which had no corresponding action_classes provisioning path in the runtime (no seed/migration anywhere creates a row with that slug) — so against a real, unmodified Atlasent org the outer gate could only ever return NO_ACTION_CLASS deny, regardless of the tool-specific inner gate's own decision. Migrating the outer gate onto agent.tool.invoke gives it the runtime's real "AI Agent Safeguard" provisioning path, which already exists for exactly this purpose. See AtlaSent/atlasent-mcp-server#121 for the full investigation and decision record.

If either Decision is non-allow or either Permit fails Verification, no deployment result is produced.

The protected-tool response includes the action-specific Verification result alongside the simulated native result:

{

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

The returned Permit has already been consumed by the execution-boundary Verification. Verifying it again should be treated as a replay, not as a step required after deployment.

Human-in-the-loop demo: hold, approve, execute, record

`examples/hitl-demo.mjs