What can you do with this server?

The Aegis server provides real-time governance policy enforcement for AI agent actions, with dynamic policy management and risk assessment. * evaluate_action: Submit an AI agent action (type, target, parameters, description, agent ID) to receive a governance decision — auto (allow), approve (needs human review), or block (deny). * evaluate_batch: Evaluate multiple actions simultaneously, receiving a decision for each. * get_policy: Retrieve the currently active governance policy, including action patterns, targets, risk levels, and approval requirements. * update_policy: Hot-reload the governance policy from a YAML string, with changes taking effect immediately — no restart required. * check_risk: Perform a lightweight risk assessment for a given action type and target, returning just the risk level and approval requirement.

Which integrations are available for this server?

Offers governance and human-in-the-loop approval gates for multi-agent workflows built using the CrewAI framework. Enables human approval workflows by sending rich embed messages to Discord for reviewing and gating agent actions. Integrates with LangChain to wrap agent actions with governance rules, providing a runtime engine for policy evaluation and audit logging. Provides a middleware layer to monitor, control, and gate actions taken by OpenAI-based agents through policy checks and approval workflows. Allows the server to govern and audit AI agent actions targeting Salesforce, such as managing CRM contacts or performing data updates. Facilitates human-in-the-loop approvals by posting action requests to Slack, allowing users to authorize or block agent actions directly from a workspace. Connects with Telegram to provide an approval interface where humans can approve or reject pending AI agent actions using inline keyboards.

de en es ja ko ru zh

aegis

by Acacian

Overview Schema Related Servers Score Discussions

Python

Hybrid

What is Aegis

Every AI agent framework reinvents the same governance primitives — and each one does it slightly differently. Aegis is the abstraction layer that unifies them.

Layer	What it does	Examples
1. Primitives	A universal contract for every tool call	`Action`, `ActionClaim`, `Policy`, `Result`, `DelegationChain`, `AuditEvent`
2. Adapters	Auto-instrument any framework through its own hooks	LangChain callbacks, CrewAI `BeforeToolCallHook`, OpenAI Agents tracing, Google ADK `BasePlugin`, MCP transport, DSPy modules, httpx middleware, Playwright context
3. Governance	Declarative primitives you compose into policy	Prompt injection / PII / leak / toxicity guardrails, RBAC, rate limit, cost budget, drift detection, anomaly scoring, trust delegation, justification gap, selection audit, Merkle audit chain
4. Lifecycle	One runtime, every stage of agent ops	Scan → Instrument → Policy CI/CD → Runtime → Proxy → Audit

import aegis
aegis.auto_instrument()    # 12 frameworks governed. No other code changes.

You don't write a LangChain guardrail and a CrewAI guardrail and an OpenAI guardrail — you write one Policy and every framework inherits it.

How this differs from the guardrail libraries

They solve a different problem, and mostly a text-shaped one. Guardrails AI validates model output against a hub of validators; NeMo Guardrails scripts conversational and tool policy in the Colang DSL; Snyk Agent Scan — Invariant Labs' mcp-scan, since the Snyk acquisition — scans MCP servers and agent skills for known risk patterns and can proxy them at runtime; LLM Guard chained input/output scanners until it was archived in July 2026. Each one you wire in yourself, at a call site you choose. Aegis starts from the other end: auto_instrument() finds the frameworks already installed and instruments them in place, so one Policy covers all of them without a line of agent code changing. What it enforces is agent-shaped rather than prompt-shaped — delegation chains under a monotone trust constraint, audits of what an agent excluded rather than what it picked, the distance between an agent's declared intent and its measured impact, and a tamper-evident audit chain. All of it is deterministic, so there is no second model sitting in the request path. These are not exclusive choices: a semantic or model-based detector drops into GuardrailEngine.add() alongside the built-ins.

Related MCP server: hejdar-mcp

Primitives

The contract every adapter maps into. Framework-agnostic by design.

Primitive	Purpose	Module
`Action`	Unified representation of any tool / LLM / HTTP / MCP call across all frameworks	`aegis.core.action`
`ActionClaim`	Tripartite structure — Declared (agent-authored) / Assessed (Aegis-computed) / Chain (delegation)	`aegis.core.action_claim`
`Policy`	Declarative YAML rules: match → risk → approval (`auto` / `approve` / `block`)	`aegis.core.policy`
`ClaimPolicy`	Policy layer that evaluates 6-dimensional impact vectors, not just tool names	`aegis.core.claim_policy`
`Guardrails`	Deterministic regex checks for injection, PII, prompt leak, toxicity — 2.65ms cold / <1µs warm	`aegis.guardrails`
`DelegationChain`	Multi-agent hand-off tracking with monotone trust constraint (non-increasing)	`aegis.core.agent_identity`
`AuditEvent`	Tamper-evident append-only log, Merkle-chained, SQLite + JSONL + webhook sinks	`aegis.core.merkle_audit`
`SelectionAudit`	Audits what an agent excludes, not just what it picks — detects cosmetic alignment	`aegis.core.selection_audit`
`JustificationGap`	6D asymmetric scoring: agents declare impact, Aegis independently assesses, gap triggers escalation	`aegis.core.justification_gap`
`CryptoAuditChain`	Ed25519-signed chain for long-term compliance evidence	`aegis.core.crypto_audit`

Every governance feature in Aegis — anomaly detection, cost budgets, drift, cascade guards, kill switches — is a composition of these primitives. Read the Concepts guide to see how they fit together.

Frameworks

One API. 12 agent frameworks + 3 protocol-level adapters.

Framework	Hook	Integration
Google ADK	`BasePlugin` lifecycle (tool calls, agent routing, sessions)	Native — the patch only installs the plugin
CrewAI	global `BeforeToolCallHook`, `Crew.kickoff/kickoff_async`	Hybrid — native hook for tool calls, patch for crew entry
Pydantic AI	`AbstractCapability` · `Agent.run/run_sync`	Native (opt-in) · Patch (auto)
OpenAI Agents SDK	`tool_input_guardrail`/`tool_output_guardrail` · `Runner.run/run_sync`	Native (opt-in) · Patch (auto)
LangChain	`BaseChatModel.invoke/ainvoke`, `BaseTool.invoke/ainvoke`	Patch
OpenAI API	`Completions.create` (chat & completions)	Patch
Anthropic API	`Messages.create`	Patch
LiteLLM	`completion`, `acompletion`	Patch
Google GenAI	`Models.generate_content` (new + legacy)	Patch
LlamaIndex	`LLM.chat/achat/complete/acomplete` on every concrete subclass, `BaseQueryEngine.query/aquery`	Patch
Instructor	`Instructor.create`, `AsyncInstructor.create`	Patch
DSPy	`Module.__call__`, `LM.forward/aforward`	Patch
MCP	Transport-layer proxy for any MCP server (stdio / HTTP)	Proxy — no patching
httpx	`HttpxExecutor` for raw HTTP egress (REST agents, webhooks)	Wrapper — no patching
Playwright	`PlaywrightExecutor` for browsing agents	Wrapper — no patching

auto_instrument() detects what's installed and patches only those — no hard dependencies. Custom adapters use the same BaseAdapter interface. Every adapter above is exercised against the current upstream release daily by the integration workflow, which drives each framework's real entrypoint and asserts a guardrail fires — the unit suite fakes these frameworks, so it cannot see upstream drift on its own.

Integration policy. Native extension points win wherever one exists that can actually block — Google ADK's BasePlugin and CrewAI's BeforeToolCallHook both do, and there auto_instrument() patches only enough to install the native object. Pydantic AI and the OpenAI Agents SDK ship native implementations you opt into (AbstractCapability, tool_input_guardrail) alongside a patch-based path for the zero-code case. Everything else is patched because no blocking hook exists: the raw OpenAI/Anthropic SDKs and DSPy expose none, and LlamaIndex's instrumentation dispatcher emits events but swallows handler exceptions, so it can observe and not enforce.

The Pydantic AI integration is the reason this policy is written down. It was monkey-patched until core maintainer DouweM reviewed it — "It doesn't look like those features are actually exposed as Pydantic AI capabilities?" — and was rebuilt on the native extension API in response (src/aegis/contrib/pydantic_ai.py; the review is pydantic-ai#4888).

Patching is the fallback, not the preference — it is the part most exposed to upstream change, which is why the integration workflow exists.

Default Guardrails

Guardrail	Default	What it catches
Prompt injection	Block	13 attack categories, 109 patterns, 9 languages (EN/KO/ZH/JA/ES/DE/FR/TH/VI)
PII detection	Warn	13 categories (email, credit card, SSN, IBAN, API keys, etc.)
Prompt leak	Warn	System prompt extraction attempts
Toxicity	Warn	Harmful, violent, or abusive content
MCP STDIO injection	Block	JSON-RPC injection, frame concatenation, unicode escape bypass (OX Security advisory)

Deterministic regex — no LLM calls, no network. 2.65ms cold / <1µs warm per check.

Use Cases

The same primitives, five different entry points. Pick whichever matches your workflow.

1. Runtime protection (most common)

One line. Any framework.

import aegis
aegis.auto_instrument()

Or zero code changes — AEGIS_INSTRUMENT=1 python my_agent.py. Injection blocking, PII masking, prompt-leak warnings, audit trail, and policy enforcement become active for every LangChain / CrewAI / OpenAI / Anthropic / LiteLLM / ADK / DSPy / LlamaIndex / Pydantic AI call.

Pydantic AI native capability — no monkey-patching, explicit per-agent control:

from pydantic_ai import Agent
from aegis.contrib.pydantic_ai import AegisCapability

agent = Agent(
    "openai:gpt-4o-mini",
    capabilities=[AegisCapability.default()],  # injection, PII, toxicity, prompt-leak, hallucination
)
result = await agent.run("What is AI governance?")

Full Pydantic AI integration guide →

2. Pre-production scanning

Find ungoverned AI calls before they ship.

pip install agent-aegis
aegis scan .

Aegis Governance Scan
=====================
Scanned: 47 files in ./src

Found 5 ungoverned tool call(s):
  agent.py:12   OpenAI        function call with tools= — no governance wrapper  [ASI02]
  tools.py:8    LangChain     @tool "search_db" — no policy check  [ASI02]
  llm.py:21     LiteLLM       litellm.completion() — no governance wrapper  [ASI02]
  run.py:5      subprocess    subprocess.run — direct shell execution  [ASI08]
  api.py:14     HTTP          requests.post — raw HTTP in agent code  [ASI07]

Governance Score: D (5 ungoverned call(s))

Supports --format json|sarif|suggest, --threshold A-F, .aegisscanignore, and inline # aegis: ignore pragmas. Auto-fix with aegis scan --fix.

3. Policy CI/CD

Security tools protect at runtime. Aegis also manages the policy lifecycle — the same way you test and ship code.

aegis plan current.yaml proposed.yaml --audit-db aegis_audit.db

# Policy Impact Analysis
#   Rules: 2 added, 1 removed, 3 modified
#   Impact (replayed 1,247 actions):
#     23 actions would change from AUTO → BLOCK

aegis test policy.yaml tests.yaml                      # Run in CI
aegis test policy.yaml --generate                      # Auto-generate test suite
aegis test new.yaml tests.yaml --regression old.yaml   # Regression check

# .github/workflows/policy-check.yml
- uses: Acacian/aegis@main
  with:
    policy: aegis.yaml
    tests: tests.yaml
    fail-on-regression: true

Or block ungoverned calls at PR time:

- uses: Acacian/aegis@v1.0.0
  with:
    command: scan
    fail-on-ungoverned: true

4. Audit & compliance

Every call is logged to a tamper-evident Merkle chain, with mappings to EU AI Act / NIST AI RMF / SOC2 built in.

aegis audit

  ID  Session       Action        Target   Risk      Decision    Result
  1   a1b2c3d4...   read          crm      LOW       auto        success
  2   a1b2c3d4...   bulk_update   crm      HIGH      approved    success
  3   a1b2c3d4...   delete        crm      CRITICAL  block       blocked

SQLite + JSONL + webhook sinks. Ed25519 signing for long-term evidence. See the Compliance guide.

5. Governance server (multi-agent)

Centralized governance for multiple agents. Each agent connects via SDK, server handles policy, guardrails, audit, and compliance.

pip install 'agent-aegis[server]'
aegis-server

37 REST endpoints + WebSocket audit streaming + web dashboard. Agents auto-register, send heartbeats, and query policy over HTTP. See Governance Framework Server.

30-Second Start

pip install agent-aegis

import aegis
aegis.auto_instrument()
# All 12 frameworks now governed with default guardrails.

Or use a YAML policy for full control:

aegis init  # Creates aegis.yaml

# aegis.yaml
guardrails:
  pii: { enabled: true, action: mask }
  injection: { enabled: true, action: block, sensitivity: medium }

policy:
  version: "1"
  defaults:
    risk_level: medium
    approval: approve
  rules:
    - name: read_safe
      match: { type: "read*" }
      risk_level: low
      approval: auto
    - name: no_deletes
      match: { type: "delete*" }
      risk_level: critical
      approval: block

Install Options

pip install agent-aegis                   # Core (includes auto_instrument for all frameworks)
pip install langchain-aegis               # LangChain standalone integration
pip install 'agent-aegis[mcp]'            # MCP server + proxy
pip install 'agent-aegis[server]'         # REST API + dashboard
pip install 'agent-aegis[all]'            # Everything

MCP Proxy — govern any MCP server with zero code changes

{
  "mcpServers": {
    "filesystem": {
      "command": "uvx",
      "args": ["--from", "agent-aegis[mcp]", "aegis-mcp-proxy",
               "--wrap", "npx", "-y",
               "@modelcontextprotocol/server-filesystem", "/home"]
    }
  }
}

Works with Claude Desktop, Cursor, VS Code, Windsurf. STDIO injection protection, tool poisoning detection, rug-pull detection, argument sanitization, policy evaluation, full audit trail.

Governance Framework Server

Run Aegis as a dedicated governance server with REST API, WebSocket streaming, and web dashboard.

pip install 'agent-aegis[server]'
aegis-server --init          # Generate aegis-server.yaml
aegis-server                 # Start server on :8000

37 REST endpoints covering the full governance lifecycle:

API Group	Endpoints	Purpose
Core	evaluate, execute, audit, policy	Policy evaluation + execution pipeline
Agents	register, heartbeat, list, status	Agent lifecycle management
Guardrails	check, list	Content safety checks
Policy Versioning	commit, diff, rollback, tag	Git-like policy change management
Crypto Audit	verify, entries, evidence	Tamper-proof audit chain verification
Trust & Drift	trust score, drift detection	Per-agent behavioral analysis
Cost	budget check, reports	LLM cost governance
Compliance	reports, regulatory gaps	SOC2 / GDPR / EU AI Act reports
Sessions	list, replay	Session recording + forensic replay

Connect with the Python SDK (sync or async):

from aegis import AegisClient

with AegisClient("http://localhost:8000", agent_id="my-agent") as client:
    result = client.evaluate("delete", "user_data")
    # result["risk_level"] == "CRITICAL", result["is_allowed"] == False

from aegis import AsyncAegisClient

async with AsyncAegisClient("http://localhost:8000", agent_id="my-agent") as client:
    result = await client.evaluate("read", "reports")

Config-driven via aegis-server.yaml — guardrails, webhooks (Slack/PagerDuty), rate limiting, cost budgets, and auth all declarative. See aegis-server.example.yaml.

Why Aegis?

	Writing your own	Platform guardrails	Enterprise platforms	Aegis
Abstraction level	Per-framework if/else	Single-vendor SDK	Proprietary gateway	Universal primitives across 12 frameworks
Setup	Days of if/else	Vendor-specific config	Kubernetes + procurement	`pip install` + one line
Code changes	Wrap every call	SDK-specific	Months of integration	Zero — auto-instruments
Policy portability	Rewrite per framework	Locked to ecosystem	Usually single-vendor	One YAML policy, every framework
Governance primitives	Build from scratch	Subset, vendor-defined	Proprietary	10+ composable primitives
Policy CI/CD	None	None	None	`aegis plan` + `aegis test`
Audit trail	printf debugging	Platform logs only	Cloud dashboard	SQLite + JSONL + webhooks + Merkle chain
Compliance	Manual docs	None	Enterprise sales cycle	EU AI Act, NIST, SOC2 built-in
Cost	Engineering time	Free-to-$$$	$$$$ + infra	Free (MIT). Forever.

What Only Aegis Does

Other tools check inputs and outputs. Aegis governs the decision itself — with primitives no other governance runtime exposes.

Capability	What it means	Based on
Tripartite ActionClaim	Every tool call splits into Declared (agent-authored, untrusted), Assessed (Aegis-computed), and Chain (delegation) fields. The structural separation is what makes cosmetic alignment detectable.	Justification Gap measurement on 14,285 tau-bench calls
Justification Gap	6-dimensional asymmetric scoring: agents declare impact, Aegis independently assesses it, and `per_dim = max(0, assessed − declared)`. Under-reporting triggers escalate (>0.15) or block (>0.40).	Name "ActionClaim" from COA-MAS (Carvalho); 6D metric + runtime form original
Selection Governance	Audits what agents exclude, not just what they choose. A model that "helpfully" omits risky options is exerting selection power — Aegis detects this.	Santander et al., arXiv:2602.14606
Monotone Trust Constraint	Delegated agents cannot escalate their own authority. Trust levels must be non-increasing along the chain — violations auto-block.	Lattice-based access control
Full Lifecycle	Scan (detect) → Instrument (protect) → Policy CI/CD (test) → Runtime (govern) → Proxy (gateway) → Audit (trace). One library, one `pip install`.	—

CLI

aegis scan ./src/                       # Detect ungoverned AI calls
aegis score ./src/ --policy policy.yaml # Governance score (0-100)
aegis init                              # Generate starter policy
aegis validate policy.yaml              # Validate syntax
aegis plan current.yaml proposed.yaml   # Preview policy changes
aegis test policy.yaml tests.yaml       # Policy regression testing
aegis check policy policy.yaml read:crm # Policy decision per action (CI gate)
aegis audit                             # View audit log
aegis serve policy.yaml                 # REST API + dashboard
aegis probe policy.yaml                 # Adversarial policy testing
aegis autopolicy "block deletes"        # Natural language → YAML

Research

Original measurements on public agent trace datasets. Stdlib-only, reproducible in 30 seconds.

The Justification Gap in 14,285 Tau-Bench Tool Calls — Formal definition of the Tripartite ActionClaim with a silent-baseline empirical study. 90.3% approve / 9.7% escalate / 0% block across four model:domain groups. Airline domain exposes ~2× the mean gap of retail. Includes soundness sketches for the three structural invariants and an honest note on the max-only override limitation discovered during the study.
Tool Distribution Drift in 1,960 Tau-Bench Trajectories — Shannon entropy on tool name sequences across GPT-4o and Sonnet 3.5 New. 39.8% of scored trajectories collapse onto one or two tools by the end. Bimodal distribution, 1.7× cross-model gap. All scripts and raw data included.

Run the same signal on your own trace:

aegis check drift --trace path/to/trace.jsonl

The CLI reads only the tool_name field — never args, CoT, or prompts — so enterprise users can score prod traces without exfiltrating PII.

We also ran aegis scan across 39 public agent repositories and graded their governance posture: 92% scored an F. That is a finding about the ecosystem, not about any one project — most agent code has no tool-call policy at all.

Documentation

Full documentation at acacian.github.io/aegis:

Integration guides — LangChain, CrewAI, OpenAI, MCP, and more
Policy reference — conditions, templates, best practices
Security features — guardrails, anomaly detection, compliance
API stability — what 1.x guarantees, and what counts as a breaking change
Architecture — how the codebase is structured
Interactive playground — try in browser, no install

Contributing

git clone https://github.com/Acacian/aegis.git && cd aegis
make dev      # Install deps + hooks
make test     # Run tests
make lint     # Lint + format check

Contributing Guide • Good First Issues • Open in GitHub Codespaces

License

MIT -- see LICENSE for details.

Available Tools

5 tools

check_riskA

Quick risk check for an action type + target combination.

    Returns just the risk level and approval requirement — lighter than evaluate_action.

    Args:
        action_type: The kind of operation.
        target: The system being acted upon.

ParametersJSON Schema

Name	Required	Description	Default
`action_type`	Yes
`target`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns risk level and approval requirement and is lighter than evaluate_action. With no annotations provided, it moderately compensates by indicating the tool is read-like and partial, but lacks details on authentication needs, rate limits, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences and a bulleted list of arguments. The first sentence clearly states the purpose, and every subsequent sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no enums) and the presence of an output schema (though not shown), the description adequately explains what it does and what it returns. It lacks only minor details about parameter constraints or advanced behavior, but is complete enough for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the tool's description elaborates on the parameters: action_type is 'the kind of operation' and target is 'the system being acted upon.' This adds meaningful context beyond the schema titles, though it could be more precise with examples or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a 'Quick risk check for an action type + target combination' and explicitly differentiates itself from the sibling evaluate_action by noting it is 'lighter'. This provides a specific verb and resource, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates this tool is 'lighter than evaluate_action' and returns only risk level and approval requirement, implying it should be used for quick checks. However, it does not explicitly state when not to use it or mention any prerequisites or alternatives beyond evaluate_action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

evaluate_actionA

Evaluate an AI agent action against the current governance policy.

    Returns a decision: auto (allow), approve (needs human review), or block (deny).

    Args:
        action_type: The kind of operation (e.g. "read_file", "send_email", "delete").
        target: The system being acted upon (e.g. "filesystem", "stripe", "database").
        params: Arbitrary parameters for the operation.
        description: Optional human-readable description.
        agent_id: Optional identifier for the agent performing the action.

ParametersJSON Schema

Name	Required	Description	Default
`action_type`	Yes
`target`	Yes
`params`	No
`description`	No
`agent_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. It discloses return decisions and parameter roles but lacks details on side effects, authentication, rate limits, or error handling. The description adds moderate transparency beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, followed by parameter explanations. It is reasonably concise without wasting words, though the bullet-style list could be more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema existing, return values are not fully described, but the description mentions three decisions. It lacks examples or constraints on parameter values. For a tool with 5 params and 0% schema coverage, the description is adequate but not deeply complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by explaining each parameter's meaning (action_type, target, params, description, agent_id). While not exhaustive, it provides sufficient context for an agent to understand required inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool evaluates an AI agent action against governance policy and returns a decision (auto, approve, block). It uses a specific verb-resource combination and distinguishes itself from siblings by focusing on individual action evaluation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like check_risk or evaluate_batch. No explicit when-to-use or when-not-to-use conditions are provided, leaving the agent to infer context independently.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

evaluate_batchA

Evaluate multiple actions at once against the governance policy.

    Each action dict should have: action_type, target,
    and optionally params, description, agent_id.

    Args:
        actions: List of action dicts to evaluate.

ParametersJSON Schema

Name	Required	Description	Default
`actions`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'evaluate' which suggests a read operation, but does not explicitly state whether it is read-only, whether it modifies state, or any side effects. Missing details on permissions, rate limits, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and includes a one-line summary followed by a bullet-like list of required fields. It could be more structured (e.g., using proper Args format), but it avoids unnecessary verbosity and is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output schema exists and may cover return values, the description does not mention what the tool returns (e.g., per-action results) or error handling. For a tool with one parameter, it covers input adequately but not output or edge cases. Some completeness is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides no parameter descriptions (0% coverage), so the description adds value by specifying that each action dict should contain 'action_type', 'target', and optionally 'params', 'description', 'agent_id'. However, it does not define the types or expected formats for these fields, leaving ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Evaluate multiple actions at once against the governance policy' and distinguishes from the sibling 'evaluate_action' by emphasizing batch processing. It also lists the required fields for each action dict, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implicitly advises using this tool for batch evaluation of multiple actions rather than single-action evaluation, but does not explicitly contrast with alternatives like 'evaluate_action' or state when not to use it. Could be more explicit about the batch vs. single distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_policyA

Get the current governance policy rules.

Returns all configured rules with their action patterns, targets, risk levels, and approval requirements.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It accurately describes a read-only retrieval operation without misleading claims. Could mention caching or latency but not necessary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that are front-loaded with the purpose and then detail. Every sentence adds value; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no parameters and has an output schema. Description explains what the output contains. For a simple retrieval tool, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters defined; schema coverage is 100%. Description adds no parameter detail because none exist, which is appropriate. Baseline 4 per rule.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get the current governance policy rules' and enumerates what is returned (action patterns, targets, risk levels, approval requirements). It distinguishes from siblings like update_policy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs. alternatives (e.g., check_risk). Implied by name, but lacking explicit when-not or context for choosing this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_policyA

Hot-reload the governance policy from a YAML string.

    The new policy takes effect immediately for all subsequent evaluations.

    Args:
        yaml_content: YAML string containing the policy rules.

ParametersJSON Schema

Name	Required	Description	Default
`yaml_content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states the effect: 'takes effect immediately for all subsequent evaluations,' which provides behavioral transparency. Since no annotations are provided, the description carries the full burden, and it adequately conveys the impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences and an Args section, front-loaded with the main action. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists and the tool is simple, the description covers the input and effect adequately. It could mention error handling or validation but is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description includes an Args section that explains the yaml_content parameter as 'YAML string containing the policy rules,' adding meaning beyond the schema, which has 0% description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Hot-reload the governance policy from a YAML string.' It specifies the verb (hot-reload), resource (governance policy), and input (YAML string), distinguishing it from sibling tools like check_risk, evaluate_action, evaluate_batch, and get_policy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that the new policy takes effect immediately, implying real-time usage. However, it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Mar 23, 2026
- First observedcheck_risk
- First observedevaluate_action
- First observedevaluate_batch
- First observedget_policy
- First observedupdate_policy

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Tools have distinct purposes, but 'check_risk' and 'evaluate_action' overlap conceptually as both assess actions, with 'check_risk' being lighter. This could cause confusion, though descriptions help differentiate.

Naming Consistency5/5

All tool names follow a consistent 'verb_noun' pattern in snake_case (e.g., 'check_risk', 'evaluate_action', 'get_policy'), ensuring clarity and predictability.

Tool Count5/5

With 5 tools covering risk checking, single evaluation, batch evaluation, policy retrieval, and policy update, the count is well-scoped for governance policy management.

Completeness5/5

The tool set covers all core operations: quick risk checks, detailed evaluations (individual and batch), and policy management (view and update), with no obvious gaps.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

acp-mcp-serverOAuth
com.agenticcontrolplane
See, price, and control every tool call your AI agents make: policy checks, cost, and audit tools.
Agent Orchestration Monitoring Security
1
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
agentguard A
io.tooloracle
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Security Monitoring
2
agentlock
io.github.Olum289
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Security Agent Orchestration
2

Related MCP Servers

NORNR MCP Control
Autonomous Agents Security
NORNR
A
license
Not graded
quality
D
maintenance
A governance and control layer for MCP tools that manages tool requests as intents through policy-based approval, queuing, or blocking. It enables secure human oversight and audit trails for consequential agent actions across platforms like Claude Desktop and Cursor.
Updated 5 months ago (2026-03-22 16:41 UTC)
1
MIT No Attribution
hejdar-mcp
Autonomous Agents Security
ARKALDA
A
license
A
quality
D
maintenance
Runtime policy enforcement for AI agents. Evaluate every agent action against your organization's policies before execution, with observe and enforce modes.
Updated 5 months ago (2026-04-15 19:06 UTC)
1
1
MIT
Proofpaneofficial
Security Shell Access Command Line
Proofpane
A
license
B
quality
A
maintenance
A governance proxy for AI tools — every MCP/agent tool call is policy-gated, secret-redacted, and written to a hash-chained, offline-verifiable audit trail.
Updated 25 days ago (2026-08-12 10:41 UTC)
13
MIT
signet-eval
Security Developer Tools
jmcentire
A
license
Not graded
quality
B
maintenance
Deterministic policy enforcement for AI agent tool calls. It evaluates every tool call against user-defined rules before execution, with no LLM in the authorization path.
Updated 9 days ago (2026-08-28 03:17 UTC)
3
MIT

Appeared in Searches

A server for orchestrating and validating AI agents

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Acacian/aegis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

What is Aegis

How this differs from the guardrail libraries

Primitives

Frameworks

Default Guardrails

Use Cases

1. Runtime protection (most common)

2. Pre-production scanning

3. Policy CI/CD

4. Audit & compliance

5. Governance server (multi-agent)

30-Second Start

Install Options

MCP Proxy — govern any MCP server with zero code changes

Governance Framework Server

Why Aegis?

What Only Aegis Does

CLI

Research

Documentation

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Proofpaneofficial

Appeared in Searches

Latest Blog Posts

MCP directory API