Guardana Control MCP server
Commit Nov 14, 2026Supervise AI agent runs by checking recorded actions against policies and enforcing approvals or vetoes.
Also known as guardana/control
- Stars
- 11
- Tools
- —
- Downloads, 30 days
- —
- Latest version
- —
- Last commit
- Nov 14, 2026
- License
- Apache-2.0
What is Guardana Control MCP?
Guardana Control is an MCP server. Supervise AI agent runs by checking recorded actions against policies and enforcing approvals or vetoes.
Summary generated from the project's README
About Guardana Control MCP server
Supervising AI agent runs by checking recorded actions against established policies is the primary function of this framework. It acts as a control and supervision layer that allows developers to decide which actions an agent can take by enforcing approvals or vetoes. The system works by consulting signed policies before a tool call is executed through an MCP gateway.
Users can implement various enforcement levels, such as holding a specific action for an expiring approval or using the AuthZEN API to let an authorization service veto configured calls. The framework also provides an Enforcement API for custom tools to ask for permission before acting. It is designed to be used with local or remote MCP setups, though it is currently in an alpha stage and should not be used as a primary security boundary.
Developers can manage tool definitions by blocking any that no longer match a reviewed fingerprint. The system records decisions into an append-only evidence trail that can be exported via OpenTelemetry. While it can observe actions across connected tools and APIs, it does not grant authority through model reasoning.
What you can do with it
- 1Enforce manual action approvalsA developer can configure the system to hold a specific tool execution until a human provides an expiring approval.
- 2Verify tool integrity via fingerprintsThe gateway can automatically block any tool whose definition has changed from its original reviewed state.
- 3Audit agent behavior with tracesDevelopers can import runtime traces and logs to inspect how well an agent followed its intended procedures.
Written from the project's README. Every use case is checked against a quote from it.
Automated checks
Ran Nov 14, 2026Full report →Not verified yet. A server needs a score of 80, no serious finding, and enough data for us to check. How checks work · What to fix for more points
- Source repository linked and reachableguardana/control is public and reachablegithub.com/guardana/control ↗Pass
- Package names this repository as its sourceNot checked
- Build provenance (Sigstore attestation)Not checked
- Open source license (OSI)Apache-2.0spdx.org/licenses/Apache-2.0.html ↗Pass
- Commit or release in the last yearLast commit or release 2026-11-14github.com/guardana/control ↗Pass
- OpenSSF ScorecardOpenSSF Scorecard 7.8 / 10; weakest: Maintained 0, Code-Review 0, Contributors 0scorecard.dev/viewer/?uri=github.com/guardana/control ↗Pass
- Package name not close to a popular packageNot checked
- No critical advisory in the package or its dependenciesNot checked
- No hidden instructions to the model0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersPass
- Destructive tools are labelledNot checked
- Remote endpoint answers the MCP handshakeNot checked
README
View on GitHubGuardana Control
Supervise your AI agents. Decide what runs.
An open-source AI agent supervision framework that checks recorded runs against procedures and uses policy to decide connected actions.
Website · Try the demo · Docs · Status · Roadmap · Contributing · Security
Try the alpha
Run the local demo: allow a call, block another and approve one exact action, without Go or a model key. Connect your MCP setup next.
The gateway is experimental. Caller identity comes from configuration.
The evidence trail is not tamper-evident. Do not deploy this as a security
boundary. Status is the inventory of what exists.
What you can do today
- Hold writes for an expiring approval of one exact action: starter policies.
- Let your authorization service veto configured calls through the AuthZEN API.
- Let a tool of your own ask before it acts, through the Enforcement API.
- Import runtime traces and egress proxy logs, inspect coverage, check a recorded run against its procedure, and stop its later calls where a signed route allows: supervision.
- Under
approvals.authority: signed, take approvals, pauses, runs and stop routes only from operators named in a signed roster: who may approve. - Block a tool whose definition no longer matches its reviewed fingerprint,
except under
OBSERVE: MCP gateway.
Supervision and reaction run when you invoke them. A stop never interrupts a running operation. Paths around the gateway stay outside its control.
The 1.0 goal: observe, supervise, react
Guardana Control is a control and supervision layer for AI agents. Its 1.0
goal is planned (roadmap):
- Observe actions and outcomes across connected tools, APIs, runtimes, network and process sources. State each path's coverage, source trust and gaps.
- Supervise runs against procedures and permissions. Report deviations, denied actions tried another way, skipped work and uncertain outcomes.
- React within scoped authority: inform, alert, request review, hold an exact action for approval, pause calls or stop further actions.
Full observation means coverage of connected paths with unknowns visible, not every action visible or controllable. Sensors report; enforcement points decide before effects. Read the product model.
How a call is decided
The MCP gateway consults signed policy before a tool call. An external PDP
can veto but never widen local authority (experimental). Its silence blocks
the calls it governs in an enforcing mode. It receives action metadata, not
arguments. Evidence names the policy version and records the outcome.
flowchart LR
accTitle: How a tool call is decided today
accDescr: The enforcement point decides an agent's proposed call from the built-in policy engine, an external decision point that can only veto, and the approval authority when a person has to approve. An allowed call goes to the tool or API. Decisions are appended to the evidence, which is exported over OpenTelemetry; a call whose record cannot be appended is blocked, unless the operator let a read run unrecorded.
AG[Agent] --> PEP[Enforcement point]
POL[Built-in policy engine] --> PEP
PDP[External PDP] -.->|can veto| PEP
APR[Approval authority] --> PEP
PEP -->|allowed call| TOOL[Tool or API]
PEP --> EV[(Append-only evidence)]
EV --> OTEL[OpenTelemetry export]
classDef accent fill:#E6F4F2,stroke:#0B8F80,color:#0F1115
class PEP accent
Decisions do not wait for evidence export. A full spool blocks calls unless the operator explicitly let a read run unrecorded.
| Verdict | Under ENFORCE |
|---|---|
ALLOW |
Proceed. |
DENY |
Block. |
REQUIRE_APPROVAL |
Hold this exact action for one approval. |
ALLOW_WITH_OBLIGATIONS |
Proceed under enforced conditions, unless advisory. |
INDETERMINATE |
No decision; never an allow. |
OBSERVE records decisions; pauses, stops and halts still block calls. No
model grants authority. Content capture is off by default; hidden reasoning
is never stored.
Connected channels towards 1.0
The planned target connects enforcement and observation through one
vocabulary (ADR-0039).
An Enforcement API
(experimental) is distinct from AuthZEN vetoes: custom tools ask before
acting and report completion or abort. A cooperating client enforces its
answer; the receiver does not.
flowchart TB
accTitle: The connected-channel target for 1.0
accDescr: The planned 1.0 target connects tools through the MCP gateway and cooperating clients over an enforcement API, and observations from runtimes, proxies and processes. A supervisor checks procedures and raises findings. Notifiers report them; scoped reactions stop later calls only at connected enforcement points. Coverage and missing observations remain explicit.
AG[Agents]
subgraph EP[Enforcement points]
MCP["MCP gateway, today"]
HK[Custom tools and framework hooks]
end
subgraph SN[Sensors]
TR[Runtime traces and logs]
PX[Proxy access logs]
PR[Process events]
end
TL[Tools and APIs]
EV[(Evidence)]
OB[(Observations)]
SV["Supervisor: procedures, detectors, coverage"]
subgraph OUT[Outputs]
AL["Alerts: webhooks, chat"]
EX["OpenTelemetry, SIEM"]
GR[Run graph]
end
RE["Reaction: scoped stops where allowed"]
AG --> MCP
AG --> HK
MCP -->|allowed calls| TL
HK --> TL
AG -.-> TR
AG -.-> PX
AG -.-> PR
MCP --> EV
HK --> EV
TR --> OB
PX --> OB
PR --> OB
EV --> SV
OB --> SV
SV --> AL
SV --> EX
SV --> GR
SV -.-> RE
classDef accent fill:#E6F4F2,stroke:#0B8F80,color:#0F1115
class MCP,SV accent
Install
Each release has archives of guardana-gateway and guardana-control for
Linux and macOS on amd64 and arm64. Download one from
releases, check it against
the signed checksums.txt (RELEASING.md) and put the
binaries on your PATH.
With Go 1.27.4 or later, build from source (version dev):
go install github.com/guardana/control/cmd/guardana-gateway@latest
go install github.com/guardana/control/cmd/guardana-control@latest
Related project: Guardana
Guardana verifies AI systems before and after deployment. Control observes and controls agents while they run. The projects are independent.
flowchart LR
accTitle: Where Guardana and Guardana Control sit in a system's life
accDescr: Guardana checks a build before its release. While the released agents run, Guardana Control observes their runs and decides connected calls. After the release, Guardana compares what changed.
B[Build] --> G1["Guardana<br/>checks before release"]
G1 --> R[Release]
R --> C["Guardana Control<br/>observes and controls runs"]
C --> G2["Guardana<br/>compares after release"]
Governance · Decision records · Code of conduct · Trademarks
Guardana Control MCP questions
Can I use this as a security boundary?
No, the evidence trail is not tamper-evident, so you should not deploy this as a security boundary.
How does the MCP gateway handle tool calls?
The MCP gateway consults signed policies before a tool call and can be configured to block tools whose definitions no longer match their reviewed fingerprint.
What happens if the external decision point is silent?
If the external PDP is silent, it blocks the calls it governs when operating in an enforcing mode.
Does the system store the content of the agent's reasoning?
No, content capture is disabled by default and hidden reasoning is never stored.