Authensor is an open-source safety layer that sits between your AI agent and the tools it uses. It checks every action against a policy before it executes, scans content for threats like prompt injection and PII leaks, and creates a tamper-evident audit trail. It works with any AI framework including LangChain, CrewAI, OpenAI Agents SDK, Claude, and MCP servers.

What is an AI agent safety layer?

An AI agent safety layer is software that intercepts actions an AI agent wants to take and decides whether those actions should be allowed, blocked, or sent to a human for approval. Think of it as a firewall for AI behavior. Without one, agents can delete files, leak credentials, make unauthorized API calls, or send data to the wrong place.

Do I need Authensor if I already use Claude, ChatGPT, or LangChain?

Yes. These tools give your agent capabilities like file access, shell commands, API calls, and web browsing. They don't have built-in policies for what's allowed. Authensor adds that missing safety layer. It works alongside any AI tool or platform you already use.

How is Authensor different from prompt engineering or system prompts?

System prompts are instructions that the AI can be tricked into ignoring through prompt injection. Authensor enforces rules in code, outside the AI model. A policy that blocks 'rm -rf' cannot be overridden by a clever prompt. It is deterministic enforcement, not probabilistic guidance.

Yes. Authensor is MIT licensed and fully open source. You can self-host everything, including the control plane with PostgreSQL, at no cost using Docker Compose. There is an optional hosted tier for teams that want managed infrastructure.

How do I get started with Authensor?

Run 'npx create-authensor' in your terminal. It generates a working project with Authensor wired in. You can choose from five templates: TypeScript agent, Python agent, Claude Code hooks, MCP Gateway, or Docker self-hosted control plane.

What AI frameworks does Authensor work with?

Authensor works with LangChain, LangGraph, CrewAI, OpenAI Agents SDK, Claude Code (via hooks), any MCP server (via the MCP Gateway), and any custom agent through the TypeScript or Python SDK. It is framework-agnostic.

Does Authensor detect prompt injection?

Yes. The Aegis content scanner includes 20+ prompt injection detection patterns covering instruction override, role manipulation, delimiter injection, encoding attacks (base64, hex, unicode), and few-shot poisoning. It runs with zero dependencies and sub-millisecond latency.

Does Authensor help with EU AI Act compliance?

Yes. Authensor maps to EU AI Act requirements for high-risk AI systems including Article 12 (record-keeping via hash-chained receipts), Article 14 (human oversight via approval workflows), Article 9 (risk management via the RedTeam harness), and Article 13 (transparency via decision logging). The EU AI Act high-risk deadline is August 2, 2026.

What is the OWASP Agentic Top 10 for 2026?

The OWASP Top 10 for Agentic Applications (2026) is a risk taxonomy developed by 100+ industry experts. It covers ASI01 Agent Goal Hijacking, ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse, ASI04 Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation, and ASI10 Rogue Agents. Authensor covers all 10 through its policy engine, Aegis scanner (15+ prompt injection rules, 22 memory poisoning rules), Sentinel behavioral monitor (EWMA/CUSUM anomaly detection), and approval workflows.

What is an MCP Gateway?

An MCP Gateway is a transparent proxy between an MCP client and any MCP server that evaluates every tool call against policies before forwarding. Authensor's MCP Gateway implements the MCP SEP authorization protocol with authorization/propose, authorization/decide, and authorization/receipt message types. It addresses the fact that 32% of MCP servers have critical vulnerabilities.

How does Authensor compare to Galileo Agent Control or NeMo Guardrails?

Authensor is the only open-source framework that provides all four pillars: tool permissions, approval workflows, cryptographic audit trails, and content safety scanning. Galileo Agent Control (Apache 2.0) provides evaluation but lacks approval workflows and receipts. NeMo Guardrails focuses on conversational safety but not tool authorization. AWS AgentCore uses Cedar policies but is AWS-locked. Authensor is cloud-agnostic, self-hostable, and MIT licensed with 924+ tests.

What AI agent frameworks does Authensor integrate with?

Authensor has official adapters for LangChain/LangGraph, OpenAI Agents SDK, Vercel AI SDK, Claude Agent SDK, and CrewAI. It also integrates with Claude Code via hooks and any MCP server via the MCP Gateway. TypeScript and Python SDKs support any custom agent framework.

MCP server security basics

The Model Context Protocol (MCP) is a standard for connecting AI agents to tools and data sources. An MCP server exposes capabilities like file access, database queries, API calls, and shell execution. An MCP client (usually an AI agent) connects to the server and calls these tools.

The problem: MCP servers have no built-in authorization. Any connected client can call any tool with any arguments. There is no policy layer, no approval workflow, and no audit trail.

Why MCP servers need security

Research has found that 32% of MCP servers have critical vulnerabilities. Common issues include:

No access control - Any connected agent can call any tool
No input validation - Tool arguments are passed through without checks
No audit logging - There is no record of what tools were called or by whom
Privilege escalation - Agents can chain tool calls to gain capabilities they should not have
Data exfiltration - Tools that read files or databases can be used to extract sensitive data

These are not theoretical risks. When you connect Claude Desktop, Cursor, or any other MCP client to a filesystem server, that agent can read any file the server has access to. If a prompt injection attack succeeds, the agent will use those tools on behalf of the attacker.

The MCP Gateway approach

An MCP Gateway is a transparent proxy that sits between the MCP client and the MCP server. Every tool call passes through the gateway, which evaluates it against a policy before forwarding it to the server.

Agent (MCP Client) -> MCP Gateway -> MCP Server -> Real World

The gateway intercepts every tools/call request, wraps it in an authorization envelope, evaluates it against your policy, and either forwards it or blocks it. From the agent's perspective, it is talking to a normal MCP server. From the real MCP server's perspective, it is receiving normal tool calls. The gateway is invisible to both sides.

Setting up an MCP Gateway

With Authensor, you configure the gateway in your MCP client config:

{
  "mcpServers": {
    "authensor-gateway": {
      "command": "npx",
      "args": [
        "@authensor/mcp-server",
        "--gateway",
        "--upstream", "npx @modelcontextprotocol/server-filesystem /tmp"
      ]
    }
  }
}

This wraps the filesystem MCP server with the Authensor gateway. Every file operation now goes through policy evaluation.

Writing policies for MCP tools

Policies define what tools can be called and under what conditions:

version: "1"
default: deny
rules:
  - tool: "read_file"
    action: allow
    constraints:
      allowedPaths: ["/tmp/", "/home/user/projects/"]

  - tool: "write_file"
    action: escalate
    reason: "File writes require approval"

  - tool: "execute_command"
    action: deny
    reason: "Shell execution is not permitted"

This policy allows file reads within specific directories, requires human approval for file writes, and blocks shell execution entirely. The default: deny means any tool not explicitly mentioned is blocked.

The SEP authorization protocol

Authensor's MCP Gateway implements the MCP SEP (Safety Extension Protocol) with three message types:

authorization/propose - The gateway proposes an action to the policy engine
authorization/decide - The policy engine returns allow, deny, or escalate
authorization/receipt - A hash-chained audit receipt is created for the decision

Every decision is logged with a SHA-256 hash chain, creating a tamper-evident record of all tool usage.

Key security practices

Default deny - Start with everything blocked and explicitly allow what is needed. This is the opposite of most MCP server configurations, which allow everything by default.

Least privilege - Give agents access to only the tools they need for their specific task. A summarization agent does not need shell access.

Constrain arguments - Do not just allow or deny tools. Constrain their arguments. Allow read_file but only for specific directories. Allow http_request but only for specific domains.

Require approval for writes - Any tool that modifies state (writes files, sends emails, makes API calls) should require human approval until you have high confidence in the agent's behavior.

Monitor patterns - Use behavioral monitoring to detect unusual tool usage. A sudden spike in file reads or a tool being called that has never been called before could indicate an attack.