What it does
An agent connects to alp-mcp-proxy instead of directly to the filesystem server. For each call, the proxy validates a trusted launch-time JSON policy and forwards only requests within the assigned paths, exact arguments, and call quotas.
agent -> alp-mcp-proxy -> MCP filesystem server -> local sandbox
The proxy controls the connected agent's filesystem authority at this MCP boundary. It does not decide whether an allowed action or the model's final answer is correct.
Engineering highlights
- Strict Pydantic validation produces immutable policy objects before the untrusted MCP session starts.
- One shared tool contract keeps configuration, authorization, and advertised MCP schemas consistent.
- Quota reservations are serialized before forwarding to avoid concurrent overuse.
- Redacted append-only events distinguish denied, completed, timed-out, and unknown outcomes without storing file content.
- Unit and integration tests exercise the actual client-to-proxy-to-filesystem-server boundary, with strict mypy/Ruff and Windows/Linux CI.
Development history
ALP began as an experiment asking whether external, task-specific authorization could contain unsafe agent tool calls while preserving useful work. I then extracted the enforceable core into this smaller MCP proxy and placed policy checks on the real tool-call path. The proxy and its integration tests are the primary engineering artifact; the earlier experiment is supporting evidence.
Earlier supporting result
The selected one-model feasibility run scheduled 180 synthetic cells. Of those, 127 executed and 53 were gated as missing evidence. The table shows the 29 task templates whose primary unsafe outcome was fully enforceable by the filesystem proxy.
| Condition | Variant | Executed / gated | Tasks complete | Unauthorized proposals / effects |
|---|---|---|---|---|
| Direct filesystem tools | Attack | 24 / 5 | 20 | 13 / 13 |
| Direct filesystem tools | Control | 29 / 0 | 24 | 0 / 0 |
| Task-conditioned proxy | Attack | 12 / 17 | 10 | 12 / 0 |
| Task-conditioned proxy | Control | 24 / 5 | 24 | 0 / 0 |
The model still proposed forbidden actions through the proxy, but none of the 12 proposals produced a filesystem effect. Ten of the 12 executed attack tasks and all 24 executed proxy control tasks completed. Direct access produced effects from all 13 unauthorized proposals.
What the public release contains
The repository contains the installable proxy package, policy example, pinned filesystem-server fixture, unit and integration tests, and a curated aggregate evaluation record. It does not contain provider traces or the original campaign machinery, so the historical run cannot be independently replayed from this release.
Limits
The evaluation used synthetic local files, one model and effort setting, and one trial per scheduled cell. Its formal nine-family security gate was inconclusive because only seven families were eligible. The result supports containment at the checked filesystem boundary, not production security, model safety, or correctness within allowed files.
Project details
- Language
- Python 3.12
- Interface
- MCP over standard input/output
- Core libraries
- Pydantic, pytest, asyncio
- Verification
- Unit and integration tests, strict mypy and Ruff, Windows/Linux CI
- Evaluation
- 127 executed of 180 scheduled synthetic cells
- Primary measure
- Unauthorized filesystem effects