What stops an agent doing something you did not allow.

Nothing consequential runs without a person

Preparing an action has no side effects. The agent reads your approved playbooks, decides what it would do, and stops. What it produces is a proposal, which sits in a queue until a person decides.

Approving is two steps, not one. The first locks the proposal and mints a short-lived token that signs the claims: what will happen, the exact parameters, whether it reaches outside your systems, and the checks that were satisfied. The person confirms against those claims, and only then does anything run. Approving a card in a queue and authorising an action are deliberately not the same gesture.

Execution checks that the token is still the proposal’s current approval, claims the proposal so it cannot be run twice, and links the receipt it writes. Backing out at the confirm step releases the proposal and revokes the token. If a release fails, the product says an approval is stranded rather than leaving it silently out of the queue.

We hold no standing access to your systems

There is no stored OAuth grant and no API key of yours in our stack. You register an endpoint you control and a signing secret, and we send signed requests to it. Your endpoint decides what to honour.

• SignedEvery request carries an HMAC-SHA256 signature over the exact bytes sent, with the timestamp, verified in constant time.
• Time-boxedA request older than five minutes is refused, so a captured one cannot be replayed later.
• KeyedEach approved action carries an idempotency key, so your endpoint can tell a retry from a second instruction.
• ScopedA connection lists the actions it will accept. A wildcard is not accepted: scoping is the point.
• TestableA reserved ping travels the same signed path and changes nothing, so you can prove the connection without performing an action.

An agent is offered only the tools its own connections allow, and a grant for a tool no connection can perform is refused rather than stored.

Sending that key is ours; recognising it is your endpoint’s, and it is worth doing properly. Keep the keys you have processed in a store of their own rather than on the record the action changed: a key held on that record is lost the moment a later action changes it, and the retry then reads as new work. The reference endpoint we publish carries exactly that limit, marked where it happens.

Secrets are blocked before they are stored

Content is scanned before any memory is written. If it contains something that looks like a live credential, the whole capture is blocked rather than trimmed: API keys, JSON web tokens, AWS and GitHub tokens, live payment keys, and database connection strings with credentials in them.

Our own secrets are held server-side. The key that writes to the database never reaches the browser, and the endpoint that performs actions refuses every request when its signing secret is absent rather than falling back to a default.

Every outcome is recorded, including the ones that did nothing

A receipt joins two halves: why the action was permitted, signed into the approval before the outcome was known, and what actually happened, with the source of each confirmation. A value re-read from the system that changed and a value echoed back from our own request look identical on a screen, so the receipt says which it is. A receipt that is missing a half, or that did not match what was promised, renders as needing review rather than as a clean result.

Approvals, declines and releases are all written to the audit trail. A change to a playbook that cannot be recorded is undone rather than kept: unrecorded governance does not stand.

Separation between teams

Records carry the team they belong to, and the tables enforce row-level security. Membership is checked server-side before a team’s playbooks, tickets or approvals are returned. A record with no team is somebody’s personal memory and is answered as though it did not exist, so nothing is said about whose it is.

What we do not have

We hold no SOC 2, ISO 27001 or comparable certification today, and we are not going to imply one. There is no bug bounty programme. If those are a requirement for you, tell us and we will be straight about where we are.

If you find a vulnerability, write to hello@conxtagents.com. We will confirm we received it, and we would rather hear about it early than read about it later.