Scarp Governance Gateway
Scarp Governance Gateway is the production implementation of Scarp's Governance layer: the parts that operate inside a single organization without requiring cross-organizational standards. It is a complete, fully functional governance product. Every agent workflow is governed end to end: content is classified, policies are evaluated, decisions are enforced in real time, sensitive data is contained, malicious activity is detected and stopped, operations can be halted at any scope, and every governed action produces a cryptographically signed evidence record the customer owns and any third party can verify.
Where the gateway sits
Scarp Governance Gateway operates as a stateless proxy between agents and the AI providers, tools, and services they interact with. All traffic routes through the gateway. The gateway classifies content, evaluates policies against the full governance scope the agent's identity carries, and enforces the decision before the call proceeds. Every governed action produces a signed evidence record.
All components deploy into infrastructure the customer controls. The root signing key remains in the customer's key store and never enters the gateway process. There is no vendor copy of data, evidence, or telemetry.
Full governance surface
Scarp Governance Gateway governs the entire agent workflow: agents, the systems they interact with, the tools they invoke, and the models they call. Every capability listed here is operational.
Content classification and DLP
PII, PHI, financial data, credentials, and adversarial content detected on every request. Redaction applied before content reaches the provider when policy requires it. Custom detection patterns supported.
Five-scope emergency controls
Immediate shutdown of governed agent activity at five granularity levels: global, provider, model, agent, and tool. The scope of the response matches the scope of the problem, avoiding the choice between tolerating a misbehaving agent and shutting down everything.
Entity lifecycle management
Providers, models, agents, tools, system identities, and policies are registered entities with default-deny posture. An unregistered entity produces an immediate block with a machine-readable reason code.
Multi-dimensional policy evaluation
Policies are composed across content classification, entity status, kill switch state, credential exposure, and adversarial signals in a single evaluation per action. Eight governance decision types enforce the full range of outcomes from allow through block to hold for human review.
Multi-hop chain tracking
Every workflow receives a gateway-generated identifier that links all evidence packs in a multi-step agent chain. The identifier is generated solely by the gateway and never accepted from agents. Chain integrity is cryptographically verifiable across hops.
Governed configuration control
Every change to governance configuration passes through a governed approval process. The configuration that governs agents is itself governed. The answer to the question every compliance framework asks: who governs the governance?
Credential and adversarial detection
API keys, connection strings, tokens, and prompt injection attempts detected in real time. Adversarial content signals projected to the customer's monitoring infrastructure alongside the signed evidence record.
Budget enforcement
Per-action spending limits enforced at the governance layer. The budget is a governance constraint, not a provider-side billing limit.
Tool and system governance
Every tool an agent invokes and every system trigger that initiates an agent workflow is a registered entity with identity-bound access control. Default-deny posture: unregistered tools produce an immediate block. Bilateral enforcement: agent permissions and tool permissions must both authorize the interaction. System triggers (schedulers, webhooks, batch processes) are governed identically to human-initiated workflows. Same policy evaluation, same evidence, same emergency controls.
Evidence the customer owns and anyone can verify
The structural property that separates Scarp Governance Gateway from every other governance system in the market. The evidence record belongs to the customer and stands on its own.
Customer-managed key store, never the gateway
Every evidence record is signed via the customer's own key store. The root signing key remains in the customer's key store and never enters the gateway process. The gateway calls the signing API through a service identity. The customer holds the keys. The gateway does not.
Customer-controlled, write-once
Evidence packs are stored in the customer's own infrastructure, one pack per record, write-once, never modified. The customer can remove the gateway entirely and retain every piece of governance evidence produced. The evidence is self-contained, portable, and verifiable without any operational dependency on the gateway operator.
Offline, independent, complete
Any third party with the public key and the evidence pack can verify the record on their own machine. No server to reach. No account to create. No callback to anyone. Change one field and verification fails. The verifier is open source and deterministic.
This property is what separates a defensible legal position from an indefensible one. AI regulation is tightening and cases are already in court. In Mobley v. Workday (US, 2024-2026), a federal court ruled that an AI vendor performing screening functions is an agent of the employer and shares discrimination liability. The class action is in discovery. In the Dutch Toeslagenaffaire (Netherlands, 2021), an algorithm used by the Dutch tax authority wrongly accused 26,000 families of welfare fraud, targeting dual-nationality holders. The government resigned. In both cases, the inability to independently verify what the AI system did prolonged harm. Independently verifiable governance evidence is what separates proof from assertion when the record is tested.
Zero telemetry. Zero aggregation
There is no aggregation service. There is no telemetry sent to the gateway operator or any third party. No phone-home. No cross-tenant data movement. The customer's governance data stays inside the customer's boundary.
AI governance evidence is a different category of data from CRM records or IT service tickets. It contains the full request and response payloads of every AI interaction. When Company A sends Company B's data through a SaaS AI governance vendor, Company A may breach its data-handling obligations to Company B, because Company B's agreement with Company A does not contemplate a third-party SaaS vendor processing that data for AI governance purposes. Scarp Governance Gateway deploys into infrastructure the customer controls. No vendor copy. No contractual exposure.
Everything inside the customer's boundary
| Component | Location | Leaves customer environment? |
|---|---|---|
| Gateway runtime | Customer infrastructure | No |
| Configuration | Customer infrastructure | No |
| Evidence packs | Customer-controlled storage | No |
| Signing keys | Customer key store | No. Root key never leaves customer key store. |
| Provider credentials | Customer key store | No |
| Administrative interface | Customer infrastructure | No |
| Operational logs | Customer infrastructure | No |
| Verifier (scarp-verify) | Auditor's machine (any platform) | N/A. Standalone binary, zero network dependency. |
| Cross-tenant telemetry | Does not exist | N/A. No aggregation, no phone-home. |
scarp-verify
The open-source standalone verification tool that answers the one question the architecture turns on: can an outside party confirm a governance record without trusting whoever produced it?
Single-pack verification
Verifies the cryptographic signature and content integrity of any individual evidence pack. Change one field and it fails.
Batch verification
Verifies a corpus of evidence packs in a single pass. Reports per-pack and aggregate results.
Chain verification
Verifies multi-hop workflow chains across evidence packs using cryptographic hash linkage. Confirms the chain is intact and correctly ordered.
Zero dependencies
Static binary. Five platforms. No runtime, no framework, no network. Bring the pack and the public key. Run it on your machine.
What SG V1 does not yet reach, and why
Governed multi-agent coordination is technically feasible to build: direct agent-to-agent communication, deep chains where each agent delegates to the next, and multi-agent swarms operating as coordinated teams. It is deliberately not shipped. The reason is that it requires answers to ten open questions, and no framework, standard, or specification has answered any of them. Scarp's four layers are interlocking; every question below ultimately requires all four to function together. The per-question layer attribution identifies where the specific unsolved primitive sits. Layer 3 (Governance) never appears because it is the one layer that is shipped. The Scarp architecture already contains answers to each of these questions. Standards need to form around them before they can be implemented, because shipping proprietary solutions to substrate problems would expose customers to migration costs and cross-jurisdictional liability when standards arrive. The engineering is straightforward. The code changes are not large. Without standards, it would be irresponsible to ship.
1. Cross-agent liability attribution (Settlement)
When Agent A delegates to Agent B and Agent B generates harmful content, who bears liability? This question applies whether the two agents belong to different operators or to the same organization. Even within a single company, delegation creates an accountability gap: which team authorized the delegated action, which budget absorbs the consequence, and which agent's governance record is the one a regulator examines. Across organizations, the question compounds: the delegator's operator? The executor's operator? Both? In what proportion? The gateway can record that delegation occurred. The evidence pack shows it. But the governance meaning of that record (who is accountable for the delegated action) has no legal or contractual framework. Shipping delegation without a liability model means customers bear unquantified risk.
2. Cross-organizational trust verification (Identity, Cooperation)
When Agent A and Agent B belong to different organizations (different gateway instances, different identity tenants, different cloud providers), who vouches for Agent B's identity and governance posture? SG's identity layer handles single-organization entity registration. Cross-org delegation requires mutual trust verification: "I trust that your governance instance governs Agent B to a standard I accept." No protocol exists for this exchange.
3. Delegation scope boundaries (Cooperation, Settlement)
When Agent A delegates to Agent B, what permissions does B receive? Agent A's full scope? A restricted subset? Who defines the restriction? The sensitivity ceiling mechanism prevents escalation within a single agent's workflow. Cross-agent scope partitioning requires governance contracts between entities that define enforceable boundaries on delegated work, and a negotiation protocol between governance instances to establish those boundaries. No standard defines either.
4. Cross-agent revocation propagation (Identity, Cooperation)
If Agent A's kill switch fires after Agent A has already delegated to Agent B, does Agent B's work stop? Kill switch checks run against the presenting agent's chain within a single continuation token. Tool-mediated workflows with separate tokens per agent do not share a token chain. Proper cross-agent revocation requires a propagation mechanism so that revoking Agent A's authority cascades to any agents working on Agent A's behalf, including agents the revoking party does not control.
5. Auditability of intent (Settlement)
In tool-mediated coordination, evidence packs prove that Agent A wrote data and Agent B read data. They do not prove Agent A intended Agent B to act on that data. More critically, they do not prove what scope or constraints Agent A intended to impose on Agent B's use of it. Intent attribution across agent boundaries is a governance primitive that requires explicit delegation declarations. No standard defines how AI agents declare delegation intent in a machine-verifiable way.
6. Sensitivity ceiling inheritance across delegation boundaries (Cooperation, Settlement)
Agent A's workflow has a sensitivity ceiling of CONFIDENTIAL. Agent A delegates to Agent B, whose own governance permits SECRET. Does the delegated work inherit Agent A's lower ceiling (secure, but restricts Agent B's capabilities) or run under Agent B's higher ceiling (permissive, but potentially violates the constraints under which Agent A's operator authorized the original workflow)? Cross-agent delegation requires a ceiling negotiation protocol: who sets the floor, who can raise it, and what evidence proves the agreed ceiling was enforced throughout the delegated work.
7. Evidence chain continuity across governance instances (Cooperation)
Within a single governance instance, SG's chain construction links every evidence pack to its predecessor via cryptographic hash. When Agent A is governed by Instance 1 and Agent B by Instance 2, the hash chain breaks at the delegation boundary. Instance 2 cannot verify the chain root because it has no access to Instance 1's evidence store. A regulator or auditor reviewing the complete workflow receives two disconnected chain fragments with no cryptographic link between them.
8. Policy reconciliation across governance instances (Cooperation, Settlement)
Agent A's governance requires human review above $50K spend. Agent B's governance permits autonomous operation up to $200K. A delegation crosses the boundary for a $75K task. Which policy governs? The question is bilateral: both governance instances must evaluate and agree before the delegated work begins. No protocol exists for governance instances to negotiate and reconcile conflicting policies at machine speed.
9. Federation across governance domains (Cooperation)
A European financial institution delegates regulatory reporting to a US analytics provider. EU AI Act obligations apply on one side. US frameworks on the other. Jurisdictional asymmetry, regulatory divergence, and governance domain boundaries that do not align with organizational or national boundaries create structural gaps no single-jurisdiction governance system resolves. A multinational running separate governance domains in the EU, US, and Singapore needs a single coherent evidence chain across all three for any workflow that spans them.
10. Dispute resolution and arbitration (Cooperation, Settlement)
Two agents' governance records disagree about what was agreed during a negotiation. Agent A's evidence says the price was $50K. Agent B's evidence says $45K. In the human world, contract law, courts, and arbitration resolve the dispute. In the agent world, no arbitration mechanism exists at machine speed. Disputes fall back to human legal processes that were not designed for the volume and velocity of machine-to-machine transactions. The Cooperation layer provides governed dispute resolution grounded in the independently verifiable evidence both parties produced. Without it, every agent-to-agent disagreement escalates to human legal processes.
The engineering is straightforward. The standards do not exist. Shipping without standards would expose customers to cross-jurisdictional liability. That risk is not ours to transfer.
Regulatory and framework alignment
Architectural alignment, not certification or compliance advice. None of these frameworks were drafted with autonomous agents in mind. All carry an assumption that becomes load-bearing the moment agents take consequential actions: the evidence of governance must be trustworthy to parties who did not produce it.