Broker & security

Built on one rule: we never hold the keys to your systems

A product that can change production permissions is worth attacking. InsightKeys is designed so that compromising our service would not be enough: the only credential that can grant access lives in a broker you run, which obeys signed instructions only, applies your own policy, and takes access away on time without us.

The design

Three parts, one direction of trust

Our cloud, or yours

Control plane

Console, API, flows, risk and agents
Holds your organisation’s instruction-signing key, sealed at rest
Holds no credential to AWS, databases or clusters
Never connects into your network

HTTPS, outbound
from the broker

Your network

Broker

Its own Ed25519 key, generated on the broker, never sent anywhere
Pins your organisation’s public key at enrollment
Your local policy file and pause switch
A local ledger that revokes at expiry

the only granting
credential

Your systems

AWS · PostgreSQL · Kubernetes

An IAM role the broker assumes
A PostgreSQL role with CREATEROLE (not a superuser)
A Kubernetes service account that may manage RoleBindings

The protocol

Every message is signed, in both directions

Enrollment

A single-use token, then a key

You create a broker in the console and get a one-time enrollment token. The broker generates its own Ed25519 key, enrolls with the token, and receives your organisation’s public key, which it pins. The token is useless afterwards.

Broker → us

Every request signed

Each poll, result, inventory and activity report is signed by the broker’s key over the time, method, path and a hash of the body, and must arrive within five minutes. A revoked broker is refused.

Us → broker

Every instruction signed

Instructions are signed with your organisation’s key. The broker rejects anything unsigned, replayed (nonce), stale (not-after), or addressed to another broker or organisation. Re-delivery is idempotent.

Local policy

Your veto, on your side

Allowed integrations, the longest grant, actions never granted (by default iam:*, organizations:*, sts:*), whether admin is allowed, and a pause switch. A refused instruction is reported and never run. Revocation is never refused.

Local ledger

Expiry on the broker’s own clock

The broker records every grant it made and revokes each at expiry itself, then reports it. An outage on our side, or a control plane that stopped sending revokes, cannot leave access in place.

Credentials

Shown once, then gone

A database password a grant creates is sealed at rest, shown to the requester once, then wiped. Integration secrets (Slack, Duo) are sealed and never returned by the API.

# broker.yaml — your policy, not ours. A signed instruction it refuses is never executed.
control_plane: https://app.insightkeys.com
name: prod-us-east-1
state_dir: /var/lib/insightkeys-broker        # its key, the pinned org key, the ledger
allow_integrations: ["prod-aws", "payments-db"]
max_duration_minutes: 240                       # the longest grant it will create, whatever it is told
deny_actions: ["iam:*", "organizations:*", "sts:*"]
allow_admin: false
paused: false                                 # true: no new grants; revocation continues
credentials:
  payments-db: {user: insightkeys_broker, password_env: PAYMENTS_BROKER_PASSWORD}
  prod-aws: {}                                # the broker's own IAM role

If our service were compromised

It could not log in to your systems — it has no credential to them
It could not grant beyond your policy — denied actions, the longest grant and allowed systems are enforced by the broker
It could not keep access alive — the broker revokes at expiry from its own ledger
You can stop everything at once — set paused: true, or revoke the broker in the console

The platform

The rest of the security model

Tenancy

Row-level security

Every tenant table is protected by PostgreSQL row-level security; the application connects as an ordinary role that the policies bind.

Identity

Your identity provider

Sign-in through OIDC from Okta, Entra ID, Google or Duo SSO, with their MFA. Roles: admin, security, approver, engineer, auditor.

Step-up

A second factor for risk

Authenticator-app codes (RFC 6238, replay-protected) or Duo push. An assertion lasts five minutes and serves one decision.

Separation of duties

Never your own approver

Two-person flows require two different approvers, neither the requester. Break-glass is always reviewed after.

Audit

Everything, in words

Every request, approval, instruction, grant, revoke and agent action, with who and when, exportable.

Agents

Bounded and reversible

Agents act only at the level you set, within a deployment ceiling, and every action can be rejected or undone.

Honest status

What has been tested, and what has not yet

We would rather you hear this from us.

How are the drivers tested?

The AWS drivers are tested against moto, the AWS API emulator; the PostgreSQL driver against a real PostgreSQL database, including logging in with the granted role and being refused on other tables; the Kubernetes driver against the API’s request shapes. Before your production, we run the broker against a sandbox account of yours with you.

Has the product been penetration-tested?

An independent penetration test is planned before the first external production customer. We will share the summary under NDA when it is done.

How is the broker packaged?

As a container image (docker run or Docker Compose) and a Python package. CloudFormation, Terraform and Helm packaging are planned.

What data does the SaaS control plane store?

Your catalog (resource names, owners, sensitivity), requests and their reasons, decisions, grants and their scoped permissions, session events the broker reports, standing-access findings and reviews. It stores no credential to your systems.

Can we run everything ourselves?

Yes. The self-hosted edition runs the same control plane images in your cloud with your PostgreSQL and identity provider.