How do I use Airlock?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Airlock submit my agent trace for redaction" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Airlock

by gatewaybuddy

Overview Schema Related Servers Score Discussions

Python

Remote

Airlock

License Python PyPI

Redaction engine + MCP server for AI agent traces. By AgentPier.

Airlock is the missing seam between your secret scanner and your PII redactor. It catches the identifiers that neither tool covers alone: AWS account IDs, ARNs, private and public IPs, hostnames, emails, access keys, bearer tokens, and high-entropy secrets — all in one pass, all replaced with typed placeholders so the lesson survives and the identifier doesn't.

Built to protect war stories: battle-tested lessons from real agent sessions, published without the infra details that would make them a reconnaissance target.

Quickstart

pip install agentpier-airlock
python -c "from airlock.scrubber import scrub; print(scrub('account 123456789012 at 10.0.0.5'))"
# → account <ACCOUNT_ID> at <PRIVATE_IP>

Or run the demo:

git clone https://github.com/gatewaybuddy/agentpier.git
cd agentpier
python examples/demo.py

Related MCP server: Fida

Demo output

========================================================================
  AIRLOCK — Redaction Demo
========================================================================

--- BEFORE (raw agent trace) -------------------------------------------
[2026-06-24T14:32:01Z] AgentRun#7f3a2c1e — inventory task started
  Caller identity: arn:aws:iam::123456789012:user/deploy-agent
  Account: 123456789012  Region: us-east-1

  Probing EC2 in us-east-1...
  → Instance i-0abc1234def56789 at 203.0.113.42 (public), 10.0.1.55 (private)
  → Security group sg-0123456789abcdef0 allows 0.0.0.0/0:443

  S3 buckets found:
    s3://example-prod-data/logs/2026-06/
    s3://example-backups/snapshots/
  Cross-account replication target: --bucket-name example-dr-replica

  Secrets Manager: arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/db-creds-xK8mP2
  Retrieved value: {"password": "s3cr3tP@ssw0rd!", "host": "db.internal.example.net"}

  Lambda env vars on arn:aws:lambda:us-east-1:123456789012:function:data-processor:
    AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
    AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

  Notification endpoint: ops-alerts@example.com
  On-call SMS: 407-555-0192
  Internal dashboard: https://monitoring.internal.example.net/dashboard

[2026-06-24T14:32:04Z] Inventory complete — 2 instances, 3 buckets, 1 function

--- AFTER (scrubbed) ---------------------------------------------------
[2026-06-24T14:32:01Z] AgentRun#7f3a2c1e — inventory task started
  Caller identity: <ARN>
  Account: <ACCOUNT_ID>  Region: us-east-1

  Probing EC2 in us-east-1...
  → Instance i-0abc1234def56789 at <PUBLIC_IP> (public), <PRIVATE_IP> (private)
  → Security group sg-0123456789abcdef0 allows <PUBLIC_IP>/0:443

  S3 buckets found:
    <BUCKET><PATH>
    <BUCKET><PATH>
  Cross-account replication target: --<BUCKET>

  Secrets Manager: <ARN>
  Retrieved value: {"password": "s3cr3tP@ssw0rd!", "host": "<FQDN>"}

  Lambda env vars on <ARN>
    AWS_ACCESS_KEY_ID=<ACCESS_KEY>
    AWS_SECRET_ACCESS_KEY=<SECRET>

  Notification endpoint: <EMAIL>
  On-call SMS: <PHONE>
  Internal dashboard: https://<FQDN>/dashboard

[2026-06-24T14:32:04Z] Inventory complete — 2 instances, 3 buckets, 1 function

--- GATE RESULT --------------------------------------------------------
  clean: False   status: DIRTY — quarantined
  findings: 22

========================================================================
  22 sensitive tokens redacted.  The lesson survives; the identifiers don't.
========================================================================

What it catches

Category	Examples	Placeholder
AWS access keys	`AKIA...`	`<ACCESS_KEY>`
Private key blocks	`-----BEGIN RSA PRIVATE KEY-----`	`<SECRET>`
Bearer tokens / passwords	`Authorization: Bearer ...`	`<SECRET>`
AWS account IDs	12-digit numeric IDs	`<ACCOUNT_ID>`
ARNs	`arn:aws:...`	`<ARN>`
S3 bucket names (in URIs)	`s3://my-bucket/`	`<BUCKET>`
Private IPs	RFC 1918 (10.x, 172.16–31.x, 192.168.x)	`<PRIVATE_IP>`
Public IPs	Routable IPv4	`<PUBLIC_IP>`
Hostnames / FQDNs	`api.example.com`	`<FQDN>`
Email addresses	`user@example.com`	`<EMAIL>`
US phone numbers	`407-555-0192`	`<PHONE>`
Absolute paths	`/home/user/.ssh/id_rsa`	`<PATH>`
High-entropy strings	Tokens, UUIDs-as-secrets (Shannon > 4.0 bits/char)	flagged by gate
Your infra names	Bucket/host names you configure	`<BUCKET>`

Usage

Scrub a string

from airlock.scrubber import scrub, gate

text = "Deployed to account 123456789012, endpoint api.example.com"

# scrub() — always redacts, returns clean string
print(scrub(text))
# → "Deployed to account <ACCOUNT_ID>, endpoint <FQDN>"

# gate() — DEFAULT-DENY: returns clean=False on ANY finding
result = gate(text)
print(result["clean"])    # False
print(result["findings"]) # [{rule: "AWS_ACCOUNT_ID", ...}, ...]

Add your org's infra names to the denylist

from airlock.scrubber import add_to_denylist
add_to_denylist(["my-prod-bucket", "internal.corp.net"])

Or via environment variable (for MCP server deployments):

export AIRLOCK_BUCKET_DENYLIST="my-prod-bucket,internal.corp.net,staging-data"
airlock-mcp

Start the MCP server

# As a console script (after pip install):
AIRLOCK_BUCKET_DENYLIST="my-bucket" airlock-mcp

# Or directly from the repo:
PYTHONPATH=. python airlock/server.py

See airlock/SKILL.md for Claude Code / Cursor install config.

Safety design

DEFAULT-DENY gate: gate() returns clean=False if anything sensitive is found. There is no partial-clean state. A story either passes the gate completely or it is quarantined.

Double-gating:

Gate on ingest — story is rejected if dirty; not stored
Scrub on egress — every return path runs scrub() (defense-in-depth)

Denylist is empty by default: Airlock ships with zero hardcoded infra names. You bring your own via AIRLOCK_BUCKET_DENYLIST or add_to_denylist(). This keeps the library from embedding any org's topology.

MCP tools

Tool	Description
`submit_story`	Submit a war story. Gate-on-ingest: rejected with findings if dirty.
`search_stories`	Keyword + tag search. All results scrubbed on egress.
`get_story`	Fetch story by UUID. Scrubbed on egress.

See airlock/SKILL.md for the full install guide and MCP config snippet.

Schema

Stories follow the AgentErrorTaxonomy. Required fields: id, title, situation, goal, what_i_tried, what_failed, what_worked, lesson, tags, narrator_id, timestamp, trust. At least one taxonomy tag is required: memory | reflection | planning | action | system.

See airlock/STORY_TEMPLATE.md for the fill-in-the-blanks template.

Running tests

# From the repo root
PYTHONPATH=. python -m pytest airlock/tests/ -v

The test suite includes unit tests for the scrubber (41 tests), handler tests (18 tests), and end-to-end subprocess smoke tests speaking real JSON-RPC 2.0 wire protocol (10 tests). All fixtures use RFC-reserved / AWS-documented identifiers — no real infrastructure values.

License

Apache 2.0. See LICENSE.

Contributing

See CONTRIBUTING.md.

Available Tools

3 tools

get_storyA

Fetch a single war story by UUID. Scrubbed on egress.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Story UUID v4.

TDQS

A3.6/5.0

Behavior3/5

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

The description adds the behavioral note 'Scrubbed on egress' beyond the implied read-only nature, but with no annotations provided, it could disclose more—such as idempotency, error handling, or permissions. It is minimally adequate.

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 short sentences convey the purpose and a key behavioral trait with no extraneous text. Every word earns its place.

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 no output schema, the description implies the return of a war story but does not specify the exact structure or error behavior (e.g., 404 if not found). For a simple fetch, most needed context is present.

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 parameter description 'Story UUID v4.' The description restates that the UUID is used for fetching but adds no new semantic value beyond the schema. Baseline score of 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 states the tool fetches a single war story by UUID, using a specific verb and resource. It distinguishes itself from siblings: search_stories (for querying multiple) and submit_story (for creating/updating).

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 is provided on when to use this tool versus alternatives like search_stories. The description does not mention prerequisites, exclusions, or context-based selection criteria.

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

search_storiesA

Search war stories by keyword and/or tag. All results are scrubbed on egress (defense-in-depth). Returns a list of matching stories.

ParametersJSON Schema

Name	Required	Description
`query`	No	Keyword to search in title, lesson, situation, goal, what_worked, what_i_tried, what_failed.
`tags`	No	Tag filter — all listed tags must be present on a story to match.
`limit`	No	Maximum number of stories to return.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that results are scrubbed on egress (defense-in-depth), which is a useful behavioral trait. However, it does not explain the extent of scrubbing or other behaviors like sorting or pagination.

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 consists of two short sentences that front-load the purpose and key behavioral note. Every word earns its place, with no fluff or redundancy.

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?

Given three parameters, no output schema, and no annotations, the description covers the core purpose and a security detail. However, it lacks information on return format, error handling, or what 'scrubbed' exactly entails, leaving some gaps for a complete understanding.

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%, so the input schema already documents all three parameters (query, tags, limit) with descriptions. The description adds no additional meaning beyond restating that it searches by keyword and/or tag, earning the baseline score of 3.

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 it searches war stories by keyword and/or tag, with a security note. It distinguishes from sibling tools 'get_story' (single story retrieval) and 'submit_story' (adding stories), as all three have distinct verbs and resources.

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 provides clear context for when to use this tool (searching by keyword/tag) but does not explicitly exclude scenarios or mention alternatives. However, the sibling tool names imply the appropriate use cases, making it clear enough.

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

submit_storyA

Submit a war story. Validated against the AgentPier schema and run through the safety gate on ingest. Rejected with findings if any sensitive data is detected (account IDs, IPs, ARNs, secrets, denylist buckets, PII). Returns the story id on success.

ParametersJSON Schema

Name	Required	Description	Default
`story`	Yes	War story object. Required fields: id (UUID v4), title, situation, goal, what_i_tried (list), what_failed (list), what_worked, lesson (max 280 chars), tags (list, must include at least one of: memory\|reflection\|planning\|action\|system), narrator_id, timestamp (ISO 8601), trust.confidence (0–1).

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description discloses validation, safety gate, rejection findings, and success output (story id). However, it omits details on idempotency, error responses, or side effects beyond mutation.

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, front-loaded with purpose, no unnecessary words. Every sentence provides essential 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 no output schema, the description adequately specifies the return value (story id). It covers validation and rejection, but could mention possible error formats or success status.

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 a detailed nested object description. The description adds context about validation and safety, but does not provide additional parameter-specific meaning beyond the schema.

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 action ('Submit a war story'), specifies the validation schema, and distinguishes it from sibling read tools (get_story, search_stories).

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 when to use the tool (submission), and mentions rejection behavior for sensitive data, but does not explicitly state when not to use or provide alternatives beyond sibling context.

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.

3 tool updatesv0.1.0Jun 25, 2026
- First observedget_story
- First observedsearch_stories
- First observedsubmit_story

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get_story fetches by UUID, search_stories searches by keyword/tag, and submit_story creates a new story. No functional overlap exists.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: get_story, search_stories, submit_story. No deviations or mixed conventions.

Tool Count5/5

Three tools form a minimal but complete set for the server's purpose: submitting, fetching individually, and searching. The count is well-scoped for a focused narrative storage system.

Completeness4/5

Covers create, read, and search operations. Missing update and delete, which may be intentional given security constraints (scrubbed on egress). Minor gap that agents can work around.

Maintenance

ActivityStale

ResponsivenessNo issues

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

MemocoreOAuth
ai.memocore
Shared memory for all your AI agents, your whole team and every MCP client — save, search, recall.
Knowledge & Memory Search RAG Systems
1
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
Occludra — MCP Gateway (AI Security Gateway)
ai.occludra
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Security Agent Orchestration
1
Scrub MCP A
com.malgorath.scrub-mcp
Stateless PII redaction over MCP/REST. Free ≤1000 words or $0.01/call; file upload supported.
Security Legal & Compliance
1

Related MCP Servers

mcp-redact
Security Developer Tools Command Line
nine710
A
license
Not graded
quality
D
maintenance
Local-first CLI and MCP server for redacting sensitive text before sharing logs, configs, and errors with AI tools.
Updated 4 months ago (2026-05-01 08:08 UTC)
MIT
Fida
Security Developer Tools Shell Access
ajipurn
A
license
A
quality
A
maintenance
A local-first redacting MCP gateway that strips secrets from file reads and shell output before they reach an AI coding agent's context, the command still runs with the real credential, but the model never sees it.
Updated 2 months ago (2026-06-28 14:39 UTC)
2
18
MIT
phi-redact-mcp
Security AI & Machine Learning
Rinava
A
license
A
quality
A
maintenance
An MCP server that redacts PII/PHI from text before it ever reaches an LLM — self-hosted, fail-closed, and HIPAA-aware.
Updated 23 days ago (2026-08-13 22:49 UTC)
3
MIT
ctxbleach
Security Developer Tools
yulinlina
A
license
Not graded
quality
C
maintenance
Local CLI and MCP server that redacts secrets from logs, files, and diffs before sending them to AI agents, with stable placeholders and token-budgeted truncation.
Updated a month ago (2026-08-07 05:54 UTC)
MIT

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/gatewaybuddy/agentpier'

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