SDK reference
Typed clients for the two synchronous lanes: gate an AI agent before it acts, and get a pre-signature verdict before a user signs.
Transport-shaped, on purpose
Every SDK is a thin client over a transport interface with two implementations: HTTP for production, in-process for embedding and CI. The in-process transport drives the live registry directly, so your tests exercise the real decision logic rather than a mock that agrees with you.
- AgentGuardrailsTransport
- HttpAgentGuardrailsTransport
- InProcessAgentGuardrailsTransport
AI Agent Guardrails: verify / gate / attest
You pass an agent id and a requirement; you get back a decision. requireTier and requireScore are the two helpers that cover most integrations.
- AgentGuardrailsSdk
- gate(agentId, req)
- GateRequirement
- GateDecision
- requireTier
- requireScore
What the SDK will never do
It reads identity, policy and reputation and returns a gate decision. It never holds a key, never moves funds and never signs on the agent's behalf. Your contract decides what to do with the answer.
Pre-signature verdicts
The wallet lane. A synchronous call before the user approves anything, returning allow / warn / block with the evidence behind it. The cheapest place in the system to stop a drain: a round-trip to an API, against a negotiation and a law firm afterwards.
- POST /v1/verdict
- allow | warn | block
- POST /v1/verdict/feedback
Alert delivery
Outbound, not an SDK call. Severity routes to the channel your on-call already reads, and every alert arrives as a threshold-signed, expiring attestation you can verify without us.
- slack
- discord
- telegram
- pagerduty
- generic webhook
Where the boundary sits.
In the same type as everything above it, and paired with the control that covers it. This is the part your auditor reads first.
Put SDK reference on your perimeter.
Engine-level detail and the full catalogue are provisioned with your engagement, alongside the console your team works in.