Ship your agent with governance built in

This page is for the company on the other side of the table: you build an AI agent and sell it, and your customers' security teams have started asking what it does inside their systems.

You have three options. Build a compliance product you never wanted to build. Keep answering the questionnaire by hand, per customer, forever. Or report into the tool your customer already uses, once, and let them answer it themselves.

How it works

Your customer does this, in their own Joopler workspace:

1. Registers your agent (name, purpose, who is accountable for it).
2. Issues it a credential. It starts with jpt_ and is bound to that one agent.
3. Pastes that credential into your product's settings.

Your agent then reports its runs into their workspace. Their evidence, their ledger, their auditor. Nothing routes through Joopler, nothing about your infrastructure changes, and you hold no compliance data on their behalf.

So your product needs two fields in its settings: an endpoint (defaults to https://api.joopler.com) and a token. Store them per customer, exactly like any other outbound integration.

The integration, in three calls

Everything below is plain HTTPS with Authorization: Bearer jpt_.... There is an SDK if you want one, but nothing here needs it.

Start a run when your agent picks up a task.

curl https://api.joopler.com/v1/agents/runs \
  -H "Authorization: Bearer jpt_CUSTOMER_TOKEN" \
  -H "content-type: application/json" \
  -d '{ "runId": "task-8841", "trigger": "webhook", "goal": "Triage inbound ticket 4471" }'

Report what it did, batched, as it works. Never send arguments: send a hash of them.

curl https://api.joopler.com/v1/agents/runs/task-8841/steps \
  -H "Authorization: Bearer jpt_CUSTOMER_TOKEN" \
  -H "content-type: application/json" \
  -d '{
    "steps": [
      { "seq": 1, "kind": "tool", "server": "zendesk", "tool": "get_ticket",
        "write": false, "argsSha256": "8c19e056...", "durationMs": 340 },
      { "seq": 2, "kind": "model", "provider": "anthropic", "model": "claude-sonnet-5",
        "tokensIn": 1840, "tokensOut": 320 }
    ]
  }'

End it, with how it went.

curl https://api.joopler.com/v1/agents/runs/task-8841/end \
  -H "Authorization: Bearer jpt_CUSTOMER_TOKEN" \
  -H "content-type: application/json" \
  -d '{ "status": "ok" }'

That is the whole integration. Each step is signed into your customer's hash-chained evidence ledger as it arrives.

Optionally, ask permission first

If you want your agent to respect the limits your customer sets (which tools it may call, when a human has to approve, a cap on writes per run), call the check endpoint before acting and honor the answer.

curl https://api.joopler.com/v1/agents/check \
  -H "Authorization: Bearer jpt_CUSTOMER_TOKEN" \
  -H "content-type: application/json" \
  -d '{ "runId": "task-8841", "server": "zendesk", "tool": "post_comment", "write": true }'

It returns allow, deny, or needs-approval. This is what turns "we log what our agent did" into "our agent will not do what you did not allow", and it is the difference most security reviews actually care about.

What you are agreeing to

Worth being direct about the boundaries, since your security team will ask.

• You never send content. Arguments go as a SHA-256 hash. Prompts and responses are not part of this API.
• The credential is scoped to one agent and one customer. It cannot read their other data, and it cannot report as a different agent. Rotating or stopping it revokes it immediately.
• Stopping is real. When your customer presses stop, the credential is revoked in the same act. Your agent will start getting 401s: for a run, for a check, and for reporting work it already did. Design for that, and fail the way your customer expects rather than crashing.
• Reported is not observed. Joopler labels what an agent reports about itself as self-reported, because that is what it is. This is deliberate, it protects the credibility of the whole record, and it still beats a screenshot.

Failing safely

Your agent should keep working when Joopler is unreachable, unless your customer wants the opposite. Both are legitimate and the SDK exposes the choice:

• Fail open (default): telemetry is best-effort, and an outage on our side never stops your product from doing its job.
• Fail closed: an action that could not be checked does not happen. Some customers in regulated environments will ask for this specifically.

Make it a setting, and say which one is the default. A customer who discovers after an incident that the answer was "we kept going" would rather have known.

What your customer gets

• Every run your agent performed, step by step, with what it touched.
• A signed, timestamped evidence record per step.
• The agent counted in their AI inventory, with a named accountable owner.
• Six agent-governance controls that can pass instead of failing, including the one that asks whether the stop button has ever been tested.

What you get

Their auditor stops asking you for screenshots. Their security review has an answer that is not a PDF you wrote about yourself. And when a competitor is asked the same questions, they are still writing the PDF.

Want help with the integration, or a test workspace to build against? Get in touch and we will set one up.