01
Attest
First, establish which workload is calling. Attestation comes from the platform itself—a SPIFFE identity, an OIDC workload token, or a cloud instance certificate—rather than distributing a shared integration API key.
How it works
Check the request. Protect the business action.
Put Trustplane before the API your agents and workflows call. Declare who may act and what they may do; verify each request locally before your application handles it. Here is the practical fit, followed by the technical sequence.
AI agent
TrustplaneEach request checked
Business API
Allowed actions continue to your API.
Unauthorized, altered or repeated requests are refused.
02
Match anchor
The attestation is matched against a trust anchor you declared in advance: the source it must come from, the network it must sit on, the window it may operate in, and the route it may reach. If the attestation does not fit an anchor, there is nothing to enroll and nothing to issue.
03
Issue passport
A matching caller receives a short-lived passport bound to that caller and that scope. It is not a portable bearer credential you can paste elsewhere — it is tied to the identity that attested and the narrow scope its anchor permits.
04
Verify request
Every request is verified locally at the boundary: the caller, the action, the audience, the route, the freshness of the proof, and whether it has been seen before. A proof is valid once, so a replayed proof is refused on arrival.
05
Decide + log
The boundary allows or denies and attaches a reason code to the outcome. Every decision — allow and deny alike — lands in an evidence-grade audit record, per request, so a later review can reconstruct exactly what happened and why.
Trust anchors
Policy in your vocabulary.
Policy in your vocabulary, not token scopes. No credential distribution. Revocation is one anchor edit.
anchor.customers-agent
source: aws.ec2 / us-east-1instance: i-38* (prefix match)network: 10.2.0.0/16window: 08:00–14:00 business daysroute: /api/customers onlyattest: cloud certificate verifiedenroll: automatic for matching agentsDeployment
Fits in front of what you already run.
- 01
Protect an existing API
A container placed in front of your existing API. Application code stays unchanged — the boundary does the verifying before a request ever reaches your handlers.
- 02
Build a new API
Keep request verification at the boundary while your application owns its business rules. Available as a container today, with an SDK on the roadmap.
- 03
Local verification
Verification uses policy held locally. The request does not need a hosted policy lookup; policy distribution and management are separate operational concerns.
Bring one workflow you need to control.
Explore the actions to allow, the requests to stop, and where Trustplane fits. Deployment and pricing are scoped to your needs.