What stops an agent doing something you did not allow.

Nothing consequential runs until it is approved

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.

An owner can later let one specific action run on its own, under a standing permission, once that action has a clean record. It is off until the owner turns it on, the receipt names the permission instead of a person, and it stops by itself after any run that was declined or could not be confirmed.

We hold only what you give us to reach your systems

For a signed endpoint we hold only its address and a signing secret: you register an endpoint you control, we send signed requests to it, and your endpoint decides what to honour. For an MCP server we hold the access token you give us, server-side only and never sent to a browser, and the agent may call only the tools you list. You can change or remove either at any time.

Microsoft 365 is connected differently, and we say so plainly. An administrator of your organisation approves the conxtagents app once, then signs in to prove they can; we store no password or token of yours, only which organisation was connected and who connected it. That approval lets our app act in your organisation, so the limits are ours to keep: the agent may use only the tools you tick, every change waits for approval and is read back afterwards, and nothing it can do deletes a user. Your administrator can withdraw the app in Microsoft Entra at any time.

• 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, requests 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.