Home / Articles / The RiskMandate partner programme: why companies that already see agents at work need the one thing their logs cannot tell them, what each agent is for, and what a partner gives, gets, and how we go to market together

The RiskMandate partner programme: why companies that already see agents at work need the one thing their logs cannot tell them, what each agent is for, and what a partner gives, gets, and how we go to market together

By Dinis Cruz · 2026-11-03 · article v1.0.0 · newsroom v0.14.50 · riskmandatepartnersbehaviour-policiesgo-to-marketagentsintegrationarticle

Abstract: Our premise has always been that RiskMandate uses whatever is already on the other side. Many products already see agents at work: gateways that sit on every call, identity services that give agents credentials, observability tools that trace them, and cost tools that read their logs and token spend. What none of them can see from their own data is what each agent is for. That is what an Agent Behaviour Policy writes down, and it turns their measurements into judgements: within mandate, over it, or with no mandate at all. So RiskMandate is starting a partner programme, with three ways in: an integration partner, which reads mandates through an API and returns findings as evidence; a referral partner; and a co-sell partner for named accounts. RiskMandate gives the mandate API, policy templates for the partner's domain, co-branding and joint case studies; a partner gives evidence that turns written rows into measured ones, finds agents nobody wrote a policy for, and opens a route to its customers. The first case study is cost, with an invented partner and a working vault. The shares and prices in this article are proposals.

In short

• Many products already see agents at work: gateways, identity, observability, cost.
• None can see what each agent is for. A behaviour policy writes it down.
• Three ways in: integration partner, referral partner, co-sell partner.
• RiskMandate gives the mandate API, templates, co-branding and joint case studies.
• A partner gives evidence, agents with no policy, and a route to its customers.
• The first case study is cost, with an invented partner and a working vault.
• Shares and prices here are proposals.

Why a partner programme

RiskMandate's premise is that we use whatever the customer already has on the other side: their gateway, their identity provider, their logs, their sandboxes. We do not want to replace any of it. We add the piece it lacks.

That piece is the same every time. A gateway knows which agent called which tool. An identity service knows who the agent is. An observability tool knows what happened. A cost tool knows what it spent. None of them knows what the agent is for, because that is not in the data; it is in the business. An Agent Behaviour Policy writes it down: the mandate, the reach, and what holds each line. With it, their measurements become judgements. Without it, a large number is just a large number.

We have already seen where we would fit with others. In WSO2's Agent Manager, a behaviour policy service plugs into the gateway's interceptor. In the cost case study, the mandate tells a cost tool which spend is the job and which is waste. A programme makes that repeatable.

Three ways in

• Integration partner. The partner's product reads RiskMandate's mandates through an API and returns its findings as evidence: measured usage, breaches, agents with no policy. The joint offer is co-branded, powered by RiskMandate. The first is the cost case study.
• Referral partner. Each side introduces customers who need the other: a partner's customer who cannot say whether their agents behave as intended, a RiskMandate customer who needs the partner's product. Proposed: a share of the first year's revenue, both ways.
• Co-sell partner. A joint offer to a named account, with one proposal, one review and joint pricing per account.

What each side gives

RiskMandate gives a partner:

• The mandate API and its schema: per agent, the purpose, the owner, the rows and the barrier on each.
• Policy templates for the partner's domain: cost rows for a cost tool, tool and data rows for a gateway, identity rows for an identity service.
• Co-branding: powered by RiskMandate.
• Joint case studies, published on this newsroom.
• A seat in the design of the policy model, as it grows.

A partner gives back:

• Evidence. A row that was an Expectation, a line in a policy, becomes a measured row. Repeated breaches become controls. That evidence is also what lets a row be priced like insurance.
• Agents with no policy. A partner sees agents nobody wrote a mandate for; each becomes a policy to write, with an owner.
• A route to its customers, who already trust it with their agents.

Going to market together

The pattern from the first case study works for any partner:

1. One design partner customer each, with agents in production and a question the partner already answers.
2. A joint report on a month of their data, with every finding judged against the mandate.
3. A published case study, with the customer's permission, and a session for the people who own the budget.
4. A packaged offer: a short review at a fixed price, then a monthly service, shared between the partners.

Each joint offer opens with one question the customer can answer yes or no to. For cost: do you understand the cost of your agents? For a gateway: do you know what each agent is allowed to call, and why? For identity: do you know which agent did this, and on whose behalf?

What we are looking for

Companies whose products already sit next to agents at work: cost and FinOps tools, AI gateways, agent identity, observability and evaluation, sandboxes and runtimes, insurers and brokers. If that is you, the cost case study shows what working together looks like, and its vault shows it running.

What this does not claim

• The programme is new: the terms, shares and prices are proposals, not a published offer.
• The first case study uses an invented partner; no partner has signed.
• RiskMandate's mandate API is described as the integration needs it; its schema is the policy model already published.

Where this comes from

My conversation of 3 November 2026, in this site's repository under admin/notes/2026-11-03__partner-programme/. The worked example: the vault.

Peer review Not reviewed yet. Review it

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles