[Sandbox] agent-airlock

### Project summary

A deny-by-default argument validation and policy layer for AI agent tool calls and MCP servers, applied as a single decorator at the call boundary.

### Project description

agent-airlock validates the arguments of a tool call before that call is dispatched. An LLM deciding to invoke a tool produces a structured call, and nothing in the usual stack checks whether that call matches the tool's contract. The model can invent parameters that were never in the signature, pass a string where an integer is required, supply an identifier it fabricated, or reuse a handle minted for a different tenant. Each of those is a well-formed, fully authorized call that does the wrong thing with authority it legitimately holds.

The project applies five layers at that boundary: stripping arguments the model invented, strict Pydantic schema validation with no type coercion, policy enforcement over which tools may be called at what rate and by which agent identity, optional execution isolation delegated to a container or micro-VM backend, and output sanitisation that masks PII and secrets before a result re-enters the model's context. It ships policy presets mapped to the OWASP Top 10 for Agentic Applications and the OWASP MCP Top 10, and a regression test per tracked CVE in the agent and MCP ecosystem, so a previously fixed attack class fails CI if it reappears.

It is needed because the containment layer below it and the authorization layer beside it both stop short of the arguments. A sandbox bounds what a call can reach. An authorization engine answers whether a principal may act on a resource. Neither has an opinion about whether the arguments are the ones the contract allows. That gap is the whole of this project's scope, and it is deliberately narrow.

Written in Python, Apache-2.0, no runtime dependency beyond Pydantic.

### Project vs Reference Architecture/Implementation

- [x] This is a reusable open source project designed for broad adoption, not a reference architecture, reference implementation, or demonstration of patterns

### Org repo URL (provide if all repos under the org are in scope of the application)

N/A

### Project repo URL in scope of application

https://github.com/sattyamjjain/agent-airlock

### Additional repos in scope of the application

_No response_

### Website URL

https://github.com/sattyamjjain/agent-airlock

### Roadmap

https://github.com/sattyamjjain/agent-airlock/blob/main/ROADMAP.md

### Roadmap context

The roadmap is built from caveats the README already states about itself, promoted to tracked work. Nothing on it is aspirational marketing.

Now: widen the AgentDojo model-in-the-loop evaluation past a single model family. The project publishes a deterministic 86.0% (524/609) upper bound alongside a much smaller realised reduction and states plainly that the two disagree by around 51 percentage points. Two OpenAI models are still one family, and published work measures attack success rates spanning 10.1% to 94.4% across models under a fixed harness, so one family cannot speak for the defense. The harness is built; the work is gated on API budget, not code.

Later: seven shipped features have no documentation page, and closing the sandbox validation gap, where a function serialised into a micro-VM bypasses the annotated validators. That hole is documented and pinned by a test so it cannot regress unnoticed, but it is real, and it is named.

The file also records what shipped rather than deleting completed items, because a roadmap that quietly drops things reads the same as one that never had them.

### Contributing guide

https://github.com/sattyamjjain/agent-airlock/blob/main/CONTRIBUTING.md

### Code of Conduct (CoC)

https://github.com/sattyamjjain/agent-airlock/blob/main/CODE_OF_CONDUCT.md

### Adopters

_No response_

### Maintainers file

https://github.com/sattyamjjain/agent-airlock/blob/main/MAINTAINERS.md

### Security policy file

https://github.com/sattyamjjain/agent-airlock/blob/main/SECURITY.md

### Standard or specification?

N/A

### Business product or service to project separation

Two reasons, one of them selfish and worth stating.

The honest one: this project needs maintainers from more than one organisation, and it will not get them on its own. It is a solo project with a narrow scope and a security posture that only holds if more than one person is reviewing it. CNCF is where the people who would be good at that already are, particularly in TAG Security, and the foundation's governance requirements would force structure that a single maintainer does not build unprompted.

The second: argument-level validation for agent tool calls is not a settled problem, and it should not be settled by a vendor. Containment is being given away by NVIDIA and Cisco, and policy languages by Amazon. The layer between them is currently one person's opinion in a Python package. Neutral governance is the difference between that becoming a shared contract and it becoming somebody's product surface.

I am not looking for promotion. I am looking for the review pressure and the succession path.

### Why CNCF?

Two reasons, one of them selfish and worth stating.

The honest one: this project needs maintainers from more than one organisation and it will not get them on its own. It is a solo project with a narrow scope and a security posture that only holds if more than one person is reviewing it. CNCF is where the people who would be good at that already are, particularly in TAG Security, and the foundation's governance requirements would force structure that a single maintainer does not build unprompted.

The second: argument-level validation for agent tool calls is not a settled problem and it should not be settled by a vendor. Containment is being given away by NVIDIA and Cisco, and policy languages by Amazon. The layer between them is currently one person's opinion in a Python package. Neutral governance is the difference between that becoming a shared contract and it becoming somebody's product surface.

I am not looking for promotion. I am looking for the review pressure and the succession path.

### Benefit to the landscape

The landscape has containment, and it has authorization. It does not have a widely used component that checks whether a tool call's arguments match the contract the tool published.

Sandboxes bound what a call can reach and hold even when every layer above them has been fooled. Policy engines answer whether a principal may act on a resource. Both are load-bearing and neither models the arguments. An authorized principal calling an authorized action with fabricated arguments passes every check the landscape currently offers.

The differentiator is scope rather than novelty: this is the piece deliberately left small enough to sit in-process, at the call boundary, before dispatch, and to compose with the layers on either side rather than replace them.

### Cloud native 'fit'

It fits as a security and policy component in the agent-serving path, not as infrastructure of its own.

The concrete cloud native surface: MCP servers are increasingly deployed as containerised services with dynamically discovered tools, which is exactly the declarative, orchestrated pattern where the caller cannot rely on the callee's contract being what it was at deployment time. The project pins tool definitions and denies on drift for that reason. Its isolation modes delegate to container and micro-VM backends rather than implementing isolation itself. Its observability is OpenTelemetry, emitting spans and metrics to an OTLP endpoint.

I will state the limit rather than stretch the claim: this is an in-process Python library, not a distributed system. It is cloud native in the sense that OPA's library form, or a policy SDK, is, by being the enforcement point inside services that are themselves cloud native. If the TOC reads that as too thin for the landscape, that is a fair question, and I would rather answer it directly than dress the project up as something it is not.

### Cloud native 'integration'

OpenTelemetry — the direct dependency-level integration. Observability is configured against an OTLP endpoint, and the project emits spans, metrics, and audit records for tool-call decisions. This is where it is most useful to the ecosystem: a denied tool call becomes a trace, not a log line.

Containers and container runtimes — sandboxed execution delegates to Docker as one of its backends. The project does not implement isolation and depends on the container ecosystem for it.

Open Policy Agent — complementary rather than integrated today. OPA decides whether a principal may call an action; this project checks the arguments of the call it permits. Those compose cleanly, and a first-class OPA integration is a reasonable thing for the TOC to push for.

### Cloud native overlap

Open Policy Agent, partially, and the overlap is worth being precise about because the projects are easy to confuse.

OPA and its policy language answer: given an authenticated principal, an action, and a resource, is this permitted? It answers that well, and this project does not try to. What OPA does not model is the arguments. An authorized principal invoking an authorized action with parameters the model invented is a permitted decision under any correct OPA policy, and it is the case this project exists for.

There is also a rate-limiting overlap with service meshes and API gateways. Theirs operates on network requests; this one operates per tool, per agent identity, inside the process, where there is no network hop to intercept. Where a gateway can see the call, the gateway is the better place to do it, and the security policy says so.

No overlap I am aware of on argument-contract validation itself.

### Similar projects

Inside CNCF: Open Policy Agent, on the authorization axis described above.

Outside CNCF: Amazon's Cedar on authorization; NVIDIA OpenShell and Cisco DefenseClaw on deny-by-default process containment for agent tools. The project's SECURITY.md compares itself to these in public and states that if a user is not already running containment, they should do that before reaching for this. MCP gateways and proxies are the nearest adjacent category and solve the same problem on the wire for people who cannot run code in the agent's process.

I am not aware of another maintained project doing argument-contract validation at the tool-call boundary. If the TOC knows of one, that is genuinely useful information, and I would rather hear it than not.

### Landscape

No. Not currently listed on the Cloud Native Landscape.

### Insights

No. Not currently listed on LFX Insights.

### Trademark and accounts

- [x] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

### IP policy

- [x] If the project is accepted, I agree the project will follow the CNCF IP Policy

### Will the project require a license exception?

N/A. The project is Apache-2.0.

### Does the project utilize any dependencies with licenses not on the allowlist or an approved exception?

N/A. The installed core is Pydantic (MIT) plus tomli (MIT) on Python 3.10 only. Both are on the CNCF allowlist. This is enforced by a bare-install CI job rather than asserted, so a dependency added outside that set fails the build. Optional extras are opt-in and are the caller's choice to audit.

### Project "Domain Technical Review"

Not yet. I have not presented to a TAG or completed the Day 0 General Technical Review questionnaire.

I am reaching out to TAG Security now and will complete the Day 0 questionnaire ahead of review. I will link the questionnaire and any meeting notes as a comment on this issue when they exist, rather than claim engagement that has not happened.

### Application contact email(s)

sattyamjain96@gmail.com

### Contributing or sponsoring entity signatory information

sattyamjain96@gmail.com — Sattyam Jain, individual maintainer. There is no sponsoring company or organisation; the project is contributed by an individual.

### CNCF contacts

None. I do not currently have contacts in CNCF leadership who know the project. I am starting with TAG Security rather than asking for an introduction.

### Additional information

Three things the TOC should weigh, stated up front rather than surfaced in review.

Single maintainer, single organisation. I am the only maintainer, and I know that is the main reason to postpone this. It is also the main reason I am applying. The commit history shows two author identities (a personal and a work address) which are both me; the project is not employer-owned, and that check was done and recorded before relicensing.

Zero open issues. The ROADMAP explains this: a previous version of that file pointed at three issues that were all closed, so a reader clicking through found nothing. The plan now lives in the file itself. This means low community volume, not an absence of tracked work, and I would rather the TOC read it correctly than assume either way.

No adopters file. I do not have named production users who have agreed to be listed, so there is no ADOPTERS.md. I would rather ship no file than an empty one.

The repository's first commit is 2026-01-31, and development has been continuous since.