Explicit routes for governed calls.

The AASG (Agentic AI Security Gateway) exposes evaluation and completion APIs, an MCP proxy, and SDK guards. Calls are governed when an integration routes them through these paths; arbitrary agent traffic is not automatically intercepted.

Built Implemented SDK and MCP paths. Live behavior must be validated for each configured deployment.

The diagram walks one illustrative call from the Acme Bank demo workspace. Integration names identify implemented code or explicit limits, not outside endorsements.

Walk it: the request path, stage by stage

Follow the SDK path. Evaluate authenticates, applies policy, records the decision, and returns the receipt. The integrated executor then runs a permitted call and reports its result to complete. The MCP proxy instead forwards configured permitted calls itself. Audit sequencing and checkpointing run separately in the background.

  1. Agent. The call starts with a named caller on any supported stack.
  2. Authenticate. The gateway checks the agent identity and credential.
  3. Evaluate. The call is matched against the pinned policy version.
  4. Decide. Policy priority and first-match ordering apply; deny wins among contributing results at the deciding priority. Holds wait for review.
  5. Receipt. Evaluate records the decision and returns its compact signed receipt before execution.
  6. Execute. The integrated SDK executor runs only a permitted or explicitly released call.
  7. Complete. The executor reports completion, status, and output; the endpoint records them without running the tool.

Diagram · illustrative call

One governed call, seven stages

Gateway request path from agent to tools Seven stages: agent, authenticate, evaluate, decide, receipt, integrated execution, completion reporting. Evaluation records the decision before execution; complete only records the reported result. Agent 01 any framework Authenticate 02 identity and credential Evaluate · policy v4 03 pinned policy version Decide · priority + rules 04 allow · deny · redactrequire_approval · log_only · escalate Receipt 05 decision recorded first Execute 06 integrated executor Complete 07 reported status + output

1 · Agent. The call starts here — a refund clerk agent built on any supported stack, asking to read one customer record.

Evaluate: stages 1–5 · Executor: stage 6 · Completion report: stage 7.

Neutrality: one gateway, many stacks

Python and Node SDKs expose explicit guard and observation APIs. Python wrappers exist for OpenAI Agents, LangChain, CrewAI, and AutoGen. A wrapper must be installed on the actual execution path; observation telemetry does not establish enforcement.

The repository contains enforcement implementations and tests. This source review does not certify every framework version, a live installation, or universal protocol compatibility. Calls outside configured guards and proxy routes remain outside this enforcement boundary.

What the repository provides for each stack, and where coverage stops
StackPathWhat exists, and its limit
MCPproxyThe implemented MCP proxy evaluates configured tool routes and forwards permitted calls to their upstream server.
A2Asession delegation, Studio handoffVerified session delegation and Studio handoff paths exist. They do not establish support for every external A2A protocol implementation.
OpenAI Agents SDKPython wrapperAn explicit Python integration wraps selected function tools with gateway checks. Wiring and the executor determine which calls are covered.
LangGraphLangChain tool wrapperThe repository provides a LangChain tool wrapper usable in compatible tool paths. This is not automatic interception of every LangGraph node.
CrewAIPython wrapperThe Python integration wraps configured crew tool entrypoints; an additional wrapper exists for AutoGen.
HTTP API and SDKsevaluate, completeCustom clients can call evaluate, enforce its response, execute permitted work, and report complete. This API is not a transparent proxy for arbitrary HTTP traffic.

Where it runs

The repository includes local Docker and hosted deployment configuration, plus implemented onboarding state and connection checks. Actual hosting location, operational readiness, and availability must be confirmed for a specific deployment.

Place guards and routes on the real execution boundary. Proof bundles can be verified offline using an independently obtained public key. See the evidence page for offline verification and the roadmap for what is built and what is next.

Next

Ghalta is in early development: this page describes a problem and an approach, not a finished product.