FAQ
Quick answers about agent governance.
The questions security, legal and platform teams ask in the first call—answered without the marketing hedge, including where the product boundary sits.
Decision boundary: Gleis evaluates each tool call against the policy your organisation approved and the evidence collected at the gateway. It does not determine legal rights, certify compliance, or replace legal review.
What Gleis is
The shortest honest description of the product and where it sits.
Gleis is an MCP gateway. Your agent points at Gleis instead of its tool servers. Every tools/call is intercepted and redacted, classified into a typed action, evaluated by a pure policy engine against the revision your organisation approved, written to a hash-chained ledger, and only then executed with a scoped, single-use credential the agent never sees. The response is evaluated again before it re-enters agent context.
No. Guardrails inspect what a model says. Gleis governs what it does. The decision is made on the tool call itself, which means it works identically whether the agent was prompted, scheduled, chained from another agent, or acting entirely on its own.
Never at decision time. A classifier is asked only what kind of action a call is, and its answer is recorded as evidence with a calibrated confidence and a pinned model version. Your rules decide what happens. Where a tool profile exists, no model is called at all.
PROCEED (permitted), CONDITIONAL (permitted under returned limits such as field scope or redaction), LICENSE (requires a recorded entitlement), REVIEW (held for a named approver in the review queue), and DENY (never reaches the upstream server). Every matching rule contributes an effect and the most severe one wins, so there is no rule priority to reason about.
Deploying it
What changes in your stack, and how long it takes.
One line of MCP configuration: the agent points at the Gleis gateway instead of the upstream tool server. No SDK, no prompt changes, no rewrite. The gateway speaks MCP in both directions, and filters tools/list so the agent only discovers what your policy could ever allow.
The gateway, policy engine, classifier, credential broker and audit ledger run in your own Azure subscription, against your PostgreSQL and your Key Vault. The Gleis control plane runs separately and only publishes signed policy bundles; it never reaches into your environment.
No, and we recommend against it. Observation mode records what your policy would have decided while every call still runs, so you get an inventory of what your agents actually attempt before anything is blocked. Most teams observe for two to four weeks, then enforce the categories their own traffic made obvious.
It denies. Classifier timeout, ledger append failure, upstream timeout, a killed engine process: each resolves to a denial with a distinct reason code and, where possible, a ledger entry. There is no proceed-if-unreachable path, which is a deliberate trade of availability for containment.
Compliance and audit
What the ledger is good for, and what it is not.
No product makes an organization compliant. Gleis produces the artifacts those regimes expect for automated action: a signed, version-controlled policy, a deterministic decision per call, the evidence considered, the reason codes, and an append-only record in your own database. The crosswalk maps rule tags to controls and ships marked unreviewed until your own owner reviews it. Your GRC owner and counsel decide what it all means for your obligations.
Yes. Entries are hash-chained and the chain is verifiable, appends are advisory-locked, and a database-level trigger enforces append-only at the storage layer. A silent edit or deletion becomes detectable rather than merely unlikely.
Not the person who wrote or proposed it. Revisions move from draft to proposed to approved to published, separation of duties is enforced in the domain layer rather than by convention, and publication signs the bundle. Rollback is a new version, never an edit of history.
The policy revision id and digest, the evaluator version, the classifier version, reason codes, matched rule ids, evidence ids, the redacted request shape digest and the compliance control tags of every matched rule. Enough to replay the decision; not enough to reconstruct your data.
Security and data handling
The boundary we hold, written plainly.
For the enforcement path, nothing. The gateway pulls signed policy bundles and pushes nothing back. Argument values are redacted in-process and never persisted raw. The control plane holds policy documents, approvals and entitlements, and receives no request payloads at all.
No. Upstream credentials stay in your Key Vault behind a managed identity and a scope allowlist. On an allowed call the broker mints a scoped, single-use, time-boxed token and the gateway injects it. Credential material is scrubbed from results and never becomes log or span data.
That is the expected failure mode and it is designed for rather than hoped away. The scenario suite carries fixtures where the classifier is wrong but confident. Tool profiles remove the model from important paths entirely, and rules on low confidence let you route uncertainty to review or denial. The classifier is a probabilistic boundary; the engine is the trust boundary.
Only the redacted shape of a call that has no tool profile: names and structure with credential-like values stripped and lengths capped, sent to a pinned classifier model. Identical shapes are served from a bounded cache, and a per-tenant token budget caps exposure. Writing tool profiles for your sensitive tools removes even that.
Next step
See it decide on your own agents.
Scope a pilot against one agent and its real tools, and run it in observation before anything is blocked.