Guardana Control MCP server
Commit 14. Nov. 2026Überwache AI Agent Runs, indem du aufgezeichnete Aktionen gegen Policies prüfst und Approvals oder Veto-Entscheidungen erzwingst.
Auch bekannt als guardana/control
- Stars
- 11
- Tools
- —
- Downloads, 30 Tage
- —
- Neueste Version
- —
- Letzter Commit
- 14. Nov. 2026
- Lizenz
- Apache-2.0
Was ist Guardana Control MCP?
Guardana Control ist ein MCP server. Überwache AI Agent Runs, indem du aufgezeichnete Aktionen gegen Policies prüfst und Approvals oder Veto-Entscheidungen erzwingst.
Zusammenfassung generiert aus dem README des Projekts
Über Guardana Control MCP server
Die Hauptfunktion dieses Frameworks ist die Überwachung von AI Agent Runs durch den Abgleich aufgezeichneter Aktionen mit festgelegten Policies. Es fungiert als Control- und Supervision-Layer, der es Entwicklern ermöglicht, durch das Erzwingen von Approvals oder Veto-Entscheidungen festzulegen, welche Aktionen ein Agent ausführen darf. Das System arbeitet, indem es signierte Policies konsultiert, bevor ein Tool Call über ein MCP Gateway ausgeführt wird.
Nutzer können verschiedene Enforcement-Level implementieren, wie zum Beispiel das Zurückhalten einer spezifischen Aktion bis zu einem zeitlich begrenzten Approval oder die Nutzung der AuthZEN API, um einen Authorization Service Veto-Entscheidungen für konfigurierte Calls zu erlauben. Das Framework stellt zudem eine Enforcement API bereit, damit Custom Tools vor einer Aktion um Erlaubnis fragen können. Es ist für die Nutzung mit lokalen oder remote MCP Setups ausgelegt, befindet sich jedoch aktuell im Alpha-Stadium und sollte nicht als primäre Security Boundary verwendet werden.
Entwickler können Tool-Definitionen verwalten, indem sie alle Tools blockieren, die nicht mehr mit einem geprüften Fingerprint übereinstimmen. Das System protokolliert Entscheidungen in einem Append-only Evidence Trail, der via OpenTelemetry exportiert werden kann. Obwohl es Aktionen über verbundene Tools und APIs hinweg beobachten kann, verleiht es keine Autorität durch Model Reasoning.
Was du damit machen kannst
- 1Manuelle Approvals für Aktionen erzwingenEin Entwickler kann das System so konfigurieren, dass eine spezifische Tool-Ausführung so lange zurückgehalten wird, bis ein Mensch ein zeitlich begrenztes Approval erteilt.
- 2Tool-Integrität via Fingerprints verifizierenDas Gateway kann automatisch jedes Tool blockieren, dessen Definition von seinem ursprünglich geprüften Zustand abweicht.
- 3Agent-Verhalten mit Traces auditierenEntwickler können Runtime-Traces und Logs importieren, um zu prüfen, wie genau ein Agent die vorgesehenen Prozeduren eingehalten hat.
Geschrieben aus dem README des Projekts. Jeder Use Case wurde gegen ein Zitat daraus geprüft.
Automatisierte Checks
Geluften am 14. Nov. 2026Vollständiger Bericht →Noch nicht verifiziert. Ein Server benötigt einen Score von 80, keine kritischen Befunde und genug Daten für unsere Prüfung. Wie die Checks funktionieren · Was du für mehr Punkte verbessern kannst
- Source Repository verknüpft und erreichbarguardana/control is public and reachablegithub.com/guardana/control ↗Bestanden
- Paket nennt dieses Repository als QuelleNicht geprüft
- Build-Provenienz (Sigstore-Attestierung)Nicht geprüft
- Open Source Lizenz (OSI)Apache-2.0spdx.org/licenses/Apache-2.0.html ↗Bestanden
- Commit oder Release im letzten JahrLast commit or release 2026-11-14github.com/guardana/control ↗Bestanden
- OpenSSF ScorecardOpenSSF Scorecard 7.8 / 10; weakest: Maintained 0, Code-Review 0, Contributors 0scorecard.dev/viewer/?uri=github.com/guardana/control ↗Bestanden
- Package-Name ähnelt keinem populären PackageNicht geprüft
- Keine kritischen Advisories im Paket oder seinen AbhängigkeitenNicht geprüft
- Keine versteckten Anweisungen an das Modell0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersBestanden
- Destruktive Tools sind markiertNicht geprüft
- Remote-Endpoint beantwortet den MCP-HandshakeNicht geprüft
README
Auf GitHub ansehenGuardana 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 Fragen
Kann ich das als Security Boundary nutzen?
Nein, der Evidence Trail ist nicht manipulationssicher, daher solltest du dies nicht als Security Boundary einsetzen.
Wie geht das MCP Gateway mit Tool Calls um?
Das MCP Gateway konsultiert signierte Policies vor einem Tool Call und kann so konfiguriert werden, dass es Tools blockiert, deren Definitionen nicht mehr mit ihrem geprüften Fingerprint übereinstimmen.
Was passiert, wenn der externe Decision Point nicht antwortet?
Wenn der externe PDP schweigt, blockiert er im Enforcing Mode die Calls, für die er zuständig ist.
Speichert das System den Inhalt der Reasoning des Agents?
Nein, das Erfassen von Inhalten ist standardmäßig deaktiviert und versteckte Reasoning wird niemals gespeichert.