For agents and machines

AI does the work. A human answers for it.

Everyone wants agents to run operations, ship code and settle payments. Almost nobody trusts them to. Every week supplies another reason not to, and dependence on them keeps growing anyway.

The problem is not agent capability. It is that nothing pins a machine action to a human who had the authority to permit it.

REMIT is the human trust chain.

Request a demo

The question REMIT answers

Is this agent, this action, this request eligible right now, given the conditions?

That is the whole job. REMIT issues short-lived, scoped authority, and that is the part everyone looks at, because it is the part you can hold. It is the output, not the control.

Authority is what REMIT issues. Eligibility is what it decides. The decision comes first, and it is the valuable half.

The same question, asked of people

Eligibility is what KeyFlux does across both families. Verifiable Credential Core asks it of a person or an organisation, and answers it over a presented credential through Resolve. REMIT asks it of a machine, and answers it over a proposed action in its own policy surface.

Two implementations of the same discipline, deliberately. There is no shared engine and no shared code between them.

How it works

Machines do not get keys. They get authority, issued at the moment of the task and gone shortly after.

01

Ask

An agent, a pipeline or a workload requests permission for a specific action.

02

Decide

REMIT evaluates eligibility: who is asking, on whose authority, over what, under what conditions, and inside what window. This step is the product.

03

Issue

REMIT mints a short-lived, scoped credential the target system enforces natively.

04

Expire

The window closes. There is nothing left to steal, replay or inherit.

05

Prove

Every request, decision and issuance is recorded, tied back to the authorising human or organisation.

KeyFlux sits in the authorisation path, not the work path

REMIT is not a jump host and not a proxy for your traffic. Credentials are issued out of band and your existing systems enforce them the way they already do.

The control is the issuance. Policy gates the credential, scope bounds it, and the time to live closes the window. Where a deployment needs enforcement inline, that is a scoped choice you make, not an architecture you inherit.

REMIT

Policy decides. Scope bounds. Time to live closes the window.

Issues a scoped, short-lived credential
Agent, pipeline or workload

Holds the credential only for as long as the task needs it.

Your target system

Enforces the credential natively, the way it already does.

Your traffic does not pass through KeyFlux. The control is the issuance.

Three deployments

REMIT SPINE

Self-hosted

The complete product, running inside your own tenancy.

In-cluster and Kubernetes first. The full pathway set and the full policy surface sit behind your boundary, so a decision about your estate is taken inside your estate.

What sits under it

  • The CI/CD pathway, for pipelines requesting authority for the deploy they are running
  • The in-cluster agent pathway, for workloads asking for scoped authority in place
  • The agent direct pathway, for an autonomous agent asking for a named action
  • The mediated pathway, for actions where the actor should never hold the credential at all
  • The full policy surface: who is asking, on whose authority, over what, and inside what window
  • Kubernetes and AWS credential issuance, live today
  • An evidence record for every request, every decision and every issuance

Each target class beyond Kubernetes is a priced module, so you pay for the systems you actually put under REMIT.

REMIT Cloud

SaaS

Hosted, and deliberately scoped to one job: CI/CD integration for DevOps pipelines.

Cloud is not a smaller SPINE and does not try to cover the same ground. It is the way a team adopts REMIT on a Tuesday afternoon without opening a procurement cycle.

Cloud imports the spine core rather than reimplementing it. The decision logic lives in one place and features flow one way, out from the spine, so there is no second implementation quietly drifting from the first.

What sits under it

  • A free community tier, which is a real way in rather than a trial
  • GitHub Actions keyless workload identity, live today
  • No long-lived secrets in your repository, because there are none to store
  • The same evidence record, tied back to the human or organisation that authorised the run

GitLab and Azure DevOps are on the roadmap. They are not shipping today and we will not imply otherwise.

REMIT Transact

HybridIn build

Financial authority for non-human actors.

The mandate is a credential. What an agent may spend, on whose authority, against which counterparties and inside what window, issued by the human or organisation that carries the liability and verifiable by anyone who has to rely on it.

Enforcement runs over every rail, and REMIT never takes custody of funds. We are not a rail, we do not hold money, and we do not take a percentage of what moves.

Deployment is a hybrid, for a reason worth stating. The authority plane is self-hosted, because your mandates and your policy belong with you. The mediation and receipt service is hosted, because the authorisation leg is mediated by design: something has to sit in the middle of the transaction that the agent itself does not control. The two halves are sold as one product.

Talk to us

What sits under it

  • Mandate as a credential, issued and revoked by the authorising party
  • Enforcement across rails, with no custody of funds at any point
  • Step-Up, the per-transaction approval plane, where a human answers in the moment
  • Receipts that re-verify after the fact, long after the transaction has cleared

Transact is in build with design partners. Talk to us if you want to shape it.

One thing worth being precise about

Transact uses credential verification to establish who is paying. SPINE does not verify credentials for AI agents. It evaluates the conditions attached to a proposed action and issues authority the target system already knows how to enforce. Two different mechanisms, and we would rather name them than blur them.

REMIT and Verifiable Credential Core share a thesis, that verified is not eligible, along with the standards we build to and the evidence discipline we hold ourselves to. They are separate engines with separate code, and nothing on this page depends on pretending otherwise.

Four pathways

SPINE ships the full set. Cloud implements the CI/CD pathway as a hosted service and stops there, on purpose.

CI/CD

Your pipeline requests authority for the deploy it is running, and gets exactly that.

In-cluster agent

A workload inside the cluster requests scoped authority for the change it needs to make.

Agent direct

An autonomous agent requests authority for a named action, and policy answers.

Mediated

For actions where the actor should never hold the credential at all, REMIT mediates the leg and the agent never touches key material.

What it covers today

Live

  • Kubernetes credential issuance
  • AWS credential issuance
  • GitHub Actions keyless, in REMIT Cloud

On the roadmap

  • SSH
  • Database access
  • Network device configuration, including Ericsson ENM
  • GitLab and Azure DevOps, in REMIT Cloud
  • Additional cloud federation

Each SPINE target class beyond Kubernetes is priced as a module.

We would rather tell you what ships than what demos.

Put a human at the end of the chain

We will walk through an agent asking, policy deciding, a scoped credential being issued, and the record that ties it back.

Request a demo