Skip to main content
Glama
ByJH
by ByJH

Airlock

A security gate for agent extensions. Airlock audits a skill, MCP server, or tool repository before it is allowed to touch your agent. Point it at an artifact and it enumerates what the artifact is, scans it for risky shapes, reads it adversarially with a model, detonates it once inside a hardened sandbox, and returns a trust scorecard with a single verdict: allow, quarantine, or block.

Python 3.10+, MIT licensed.

The problem

Agents now install extensions the way apps install packages. A skill is a folder with a SKILL.md and some scripts; an MCP server is a one-line add. Both run with access to your tools, your files, and your environment. The registries that host them are filling faster than anyone is vetting them, and roughly one in eight public skills has been found to carry a critical vulnerability.

The extension you install today can read your ~/.aws/credentials, dump your environment to a remote host, or hide a line in its SKILL.md that tells your agent to reveal its system prompt. A careful manual review is thirty to sixty minutes of an expert reading code and declared permissions. Most people skip it and install on faith.

Related MCP server: Heron

What Airlock does

Airlock turns that manual review into a repeatable fifteen-second gate. It runs five stages, and the gate at the end is deterministic, so a model is never the last word on whether something dangerous gets in.

  1. Recon enumerates the artifact's bill of materials: its files, its SKILL.md frontmatter, its declared permissions, and its executable entrypoints.

  2. The static scan matches the code and the SKILL.md against a corpus of risky shapes: credential-file reads, environment exfiltration, base64 and network pairings, reverse-shell patterns, package lifecycle hooks, and prompt-injection phrasing.

  3. The adversarial judge, a Gemini model, reads the artifact for intent the patterns miss: a novel exfiltration path, an injection buried in prose, a mismatch between what SKILL.md promises and what the code does.

  4. The sandbox trial detonates the artifact once inside a container with no network, a read-only root, every Linux capability dropped, and hard caps on memory, processes, and time. The environment is seeded with canary secrets. If the artifact reaches for one, Airlock sees it.

  5. The trust policy fuses every signal into a grade, a tier, and a verdict. A critical finding, a canary touch, or a judged exfiltration is always a block. The model can escalate a verdict; it can never relax one.

How it works

Recon runs first and hands every later stage the same bill of materials. The static scan, the judge, and the sandbox then examine the artifact independently; none of them sees another's output, so a miss in one can't propagate. The trust policy fuses the three signals into the grade, the tier, and the verdict the scorecard reports.

The static scan and the judge are deliberately decorrelated: one matches known shapes, the other reasons about intent, and either can catch what the other misses. The sandbox turns a claim into an observation. The trust policy is plain code, so the same artifact always gets the same verdict, and a wrong or absent judgment can only ever be safe. See docs/architecture.md for the data flow and docs/security-model.md for the threat model, including how Airlock defends itself against an artifact that tries to prompt-inject the auditor.

Quickstart

conda create -n airlock python=3.12 -y
conda activate airlock
pip install -e ".[sandbox,dev]"

# Audit a known-bad example. Deterministic core, no key needed.
airlock audit examples/malicious-skill --no-llm

# Audit a safe one.
airlock audit examples/benign-skill --no-llm

The malicious example comes back grade F, blocked, with the injection line and the credential read cited. The benign one comes back grade A, allowed. Exit codes gate a pipeline: 0 allow, 1 quarantine, 2 block.

Turn on the full pipeline with a key and Docker running:

cp .env.example .env        # then set GOOGLE_API_KEY
airlock audit examples/malicious-skill

The sandbox trial detonates the example and reports the canary secrets it emitted. A Google AI Studio key enables the adversarial judge.

To see the whole flow in one place, notebook/airlock_demo.ipynb audits the malicious and benign examples, runs the eval, and falls back to the deterministic core when there is no key or Docker. On Kaggle it reads GOOGLE_API_KEY from Secrets.

Airlock also runs as an MCP server, so an agent can gate an install without shelling out:

airlock-mcp        # or: python -m airlock.mcp_server

It speaks JSON-RPC over stdio and offers one tool, audit_extension(path, use_llm?, use_sandbox?), that returns the same verdict the CLI does. The tool defaults to the deterministic core, so it answers with no key and no Docker.

Demonstrated concepts

Airlock is built for the AI Agents Intensive capstone and demonstrates the course concepts with working code, not claims.

Concept

Where it lives

Multi-agent system (ADK)

src/airlock/agents/adk_pipeline.py: a SequentialAgent of scanner, judge, and gate agents

Security features

the whole product: sandboxing, deterministic guardrails, injection defense (docs/security-model.md)

Deployability

Dockerfile and src/airlock/server.py for Cloud Run; notebook/airlock_demo.ipynb runs it end to end in Kaggle

Agent skills

Airlock audits SKILL.md skills and ships as one you can install (skill/SKILL.md)

MCP server

src/airlock/mcp_server.py exposes audit_extension over MCP so an agent can gate an install inline

Evaluation

eval/run_eval.py scores detection accuracy over a labeled corpus

Evaluation

python eval/run_eval.py          # deterministic core, reproducible offline
python eval/run_eval.py --full   # with the judge and the sandbox

The script runs the gate over eval/labels.json, a hand-built corpus of 22 fixtures: 10 malicious extensions covering distinct attack shapes (credential-file reads, environment exfiltration, a reverse shell, a curl | bash installer, an npm postinstall hook, SKILL.md prompt injection, an obfuscated loader, and an MCP server that scrapes the environment) and 12 benign utilities, several of which look suspicious but are not, like a base64 tool and a password-strength checker.

On the deterministic core the gate catches all 10 malicious fixtures and clears all 12 benign ones: recall 100%, precision 100%. Every malicious fixture is inert, targets a non-routable .invalid host, and carries a header marking it a test fixture. tests/test_corpus.py asserts each fixture still reaches its labeled verdict, so a rule change that breaks the number fails the build. Add a folder under eval/fixtures/, label it in eval/labels.json, and rerun.

Roadmap

  • Live MCP-server auditing by connecting to a target server and trialing its declared tools, not just reading its manifest.

  • An egress detector in the sandbox: a fake metadata endpoint and a DNS sink, so a silent exfiltrator that swallows its errors is still caught.

  • The runtime side: watch an installed extension's behavior over time, not just at install.

  • More languages in the scanner and the sandbox beyond Python and shell.

License

MIT. See LICENSE.

Available Tools

1 tool
audit_extensionA

Audit an agent extension (a skill folder with a SKILL.md, an MCP server, or a tool repo) before installing it. Returns a verdict of allow, quarantine, or block with line-level findings.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the extension to audit.
use_llmNoRun the Gemini judge (needs GOOGLE_API_KEY). Default false.
use_sandboxNoDetonate in the Docker sandbox (needs Docker). Default false.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations provided. The description discloses the return of a verdict and line-level findings, and mentions optional LLM and sandbox usage. It does not discuss potential side effects, permissions, or if the tool is read-only, leaving some behavioral ambiguity.

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 sentences convey the core purpose and outcome efficiently, with no extraneous information. The structure is front-loaded and to the point.

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?

The description lacks details about the return format (structure of verdict and findings) and does not specify if the tool is read-only or has side effects. With no output schema, more information would be helpful for completeness.

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?

Schema coverage is 100% with adequate descriptions for all three parameters. The tool-level description does not add additional meaning beyond the schema, but given high coverage, baseline score 3 is appropriate.

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 specifies the action (audit), the resource (agent extension), and the expected output (verdict with line-level findings). It distinguishes the tool's purpose without ambiguity.

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 states the tool is for auditing before installation, which implies its usage context. However, it does not explicitly exclude scenarios or mention alternatives, but with no sibling tools, this is adequate.

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.

  1. 1 tool updatev0.1.0
    • First observedaudit_extension

TDQS

A3.8/5.0
Disambiguation5/5

Only one tool exists, so there is no risk of confusion between tools.

Naming Consistency5/5

The single tool name 'audit_extension' follows a clear verb_noun pattern, consistent with best practices.

Tool Count2/5

With only one tool, the server seems under-scoped for typical use cases involving extension management, such as installation or listing.

Completeness2/5

The server only provides an audit function, missing essential operations like install, remove, or list extensions, leading to significant gaps.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Security scanning for AI agent skills, MCP servers, and agent prompts, returning signed trust scores and detailed findings.
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    A zero-trust security gateway for MCP tool calls, inspecting tool identity, arguments, execution decisions, and returned content before risk reaches your coding agent.
    Apache 2.0
  • A
    license
    Not graded
    quality
    D
    maintenance
    A defensive gateway and firewall for AI agents using MCP servers, scanning tool calls, responses, and manifests for prompt injection, secrets, dangerous commands, and drift before allowing execution.
    MIT

Latest Blog Posts

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/ByJH/airlock'

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