Inherited credentials
An agent often runs with a developer’s or a service account’s credentials, so it can reach whatever they can reach.
Changed arguments need approval again.
The problem
An agent often runs with a developer’s or a service account’s credentials, so it can reach whatever they can reach.
Connecting an MCP server or tool gives the agent a capability. It does not establish that the organization has authorized this use of it.
Prompts can be manipulated and plans can drift. The decision to act must not rest on the agent’s own account of what it is doing.
Action gate
Before a consequential tool call runs, AtlaSent evaluates it against who the agent is acting for, what it may do, to which resource, and under which conditions. The call proceeds only with a permit bound to that exact action, verified where it executes. If authority cannot be established, the call is refused and nothing runs.
A connected tool, MCP capability, or authenticated session does not silently inherit organizational authority.
An error, a timeout or a malformed answer is a refusal, not a pass. There is no fallback that lets the action through.
The agent has its own verified identity, kept separate from the person it acts for. The runtime seals the request it evaluates, and the permit is bound to that exact action, so an agent cannot borrow someone else’s identity or swap the action after the decision.
When your rules require a person, the action is held and nothing runs in the meantime. The approval is claimed with the agent’s own identity and bound to the approved plan; a changed plan needs a new approval.
The runtime supports defense controls that refuse a whole class of agent actions at once, for example agent actions that arrive without provenance the runtime sealed itself. How your organization uses them is scoped with you.
Execution and effect proof
Allow, refuse or hold, with the reason and the requirements it was measured against.
The short-lived, single-use permit is checked where the action executes. A different action does not verify.
Recorded when the execution is actually observed or reported, never inferred from the decision.
The downstream result is kept separate and marked verified only where it has been verified.
Design partner program
AI Action Protection is offered through a design partner program. We start from the agents you run, the tools they can reach and the one consequential action you most need to control, and confirm in the engagement exactly what is protected. Nothing is inferred from this page.
Which agents and hosts you use, which tools and credentials they hold, which actions would hurt if they ran without the right person’s approval, and who in your organization owns that decision.
For developers
Add the AtlaSent MCP server with npx -y @atlasent/mcp-server. With no API key it runs in local mode: a credential-free demo with unsigned permits that protects nothing. Add a free API key to get real decisions, signed permits and receipts from your organization's policies.
For developers
Put protect() in front of the consequential tool effect. An agent with a working credential but no delegated authority is refused before the effect happens.
$ npm install @atlasent/sdk
import atlasent, { AtlaSentDeniedError } from "@atlasent/sdk";
try {
await atlasent.protect({
agent: "deploy-bot",
action: "production.deploy",
context: { environment: "production", commit: sha },
});
await deploy(sha); // runs only with a verified permit
} catch (err) {
if (err instanceof AtlaSentDeniedError) halt(err.reason);
}