A product that grants access to production is, by design, one of the most powerful systems in your estate. If it is compromised, an attacker does not need to escalate privileges; the tool will do it for them. So any access vendor should expect a hard security review, and any security team should know which questions matter. This post sets out those questions, and answers each one for InsightKeys — including where the honest answer is “not yet”.
The questions apply to any vendor that will change your production permissions: just-in-time platforms, privileged access management suites, cloud entitlement tools with remediation features, or a home-built bot. Use them as a checklist; the answers will differ.
In short
- Ask first where the granting credential lives. In InsightKeys it lives only in a broker that runs in your network; our servers never hold a credential that can change your permissions.
- Ask what a compromised vendor could do. Here, it could only send signed instructions that your broker checks against a local policy file you own, and revocation still runs.
- Ask what happens when the vendor is down. The broker keeps a local ledger and revokes at expiry on its own clock.
- Ask about the people, not only the machines. Single sign-on with your identity provider’s MFA, step-up for risky requests, approvers who are never the requester.
- Ask what is not done yet. For InsightKeys: an independent penetration test before the first external customer, and packaging beyond Docker, are planned.
Why the broker is the target
Every access tool has to hold, somewhere, a credential that can change permissions: an AWS role that can create permission sets, a database role that can create logins, a Kubernetes service account that can create RoleBindings. Whoever holds that credential holds the keys to the estate. The architecture question is simple to ask and decisive to answer: where is it, and what stops it being misused?
Many software-as-a-service tools hold that credential in the vendor’s cloud, often as a cross-account role or an API token the customer provides. That is convenient, and it makes the vendor’s security your security. InsightKeys was designed around the opposite rule: our servers never hold a credential that can change a customer’s permissions.
The broker connects out, checks every instruction, and alone holds the credential that changes permissions.
The questions, answered
| Question to ask | InsightKeys answer |
|---|---|
| Where does the credential that can change permissions live? | Only in the broker, a small service you run. It holds an IAM role it assumes, a Postgres role with CREATEROLE, or a Kubernetes service account. The control plane never receives it. |
| What can connect to the broker? | Nothing. It connects out over HTTPS only; no inbound port is opened. |
| How does the broker prove who it is? | With its own Ed25519 key, generated on the broker and never sent anywhere. Enrolment uses a single-use token. |
| How does the broker know an instruction is genuine? | Instructions are signed with your organisation’s Ed25519 key, pinned at enrolment. Unsigned, replayed (nonce), stale (not_after) or misaddressed instructions are rejected; re-delivery is idempotent. |
| What limits a genuine but harmful instruction? | A local policy file you own (broker.yaml): which integrations it may touch, the longest grant it will create, actions it will never grant (by default iam:*, organizations:* and sts:*), whether admin may be granted, and a pause switch. |
| What happens if the vendor is down? | The broker keeps a local ledger (SQLite) of what it granted and revokes at expiry on its own clock. It reports expiries when it can reach the control plane. |
| Can revocation be blocked? | No. The pause switch stops new grants; revocation keeps running. The broker never refuses a revocation. |
| What about database passwords? | Credentials a grant creates are sealed at rest, shown to the requester once, then wiped. |
| How are tenants separated? | In the SaaS edition, by PostgreSQL row-level security. A self-hosted edition runs from the same images, with the same broker. |
If the vendor is compromised
This is the question that matters most, and the one most worth testing in a review. Suppose an attacker fully controls the InsightKeys control plane. What can they do to your estate?
They cannot use a stored credential to change your permissions, because there is none to steal. They cannot connect to your broker, because it accepts no inbound connections. What they could attempt is to issue instructions to your broker. That is where the second line holds: the broker applies its own local policy before acting. It will not touch an integration you have not allowed, will not create a grant longer than your limit, will not grant the actions you have forbidden — by default anything in IAM, AWS Organizations or STS — and will not grant admin unless you have said it may. You can stop all new grants with the pause switch, locally, without our cooperation.
Be precise about the residual risk
A compromised control plane that can produce validly signed instructions could request grants that fall within your local policy. The local policy is therefore your real ceiling, and it should be set as tightly as your operations allow: short maximum durations, the default forbidden actions kept, admin disabled where it is not needed. What a compromised control plane cannot do is leave a grant in place by withholding the revoke: the broker revokes at expiry from its own ledger.
The same design handles the more ordinary failure: an outage. If the control plane is unreachable, access does not linger. Grants that were due to expire are removed by the broker on time, and the record catches up when the connection returns.
What is created in your systems, and how it is removed
Reviewers should also ask what a grant physically is, because that determines how cleanly it can be removed and how easily it can be audited from your side, independent of the vendor.
| Integration | What the broker creates per grant | How it is removed |
|---|---|---|
| AWS IAM Identity Center | A permission set named IK-… with an inline least-privilege policy and a session duration no longer than the grant, assigned to the person’s Identity Center user | Assignment and permission set deleted at expiry |
| AWS IAM | A role only the person’s principal may assume, with the scoped policy inline | Role deleted at expiry |
| PostgreSQL | A login role with VALID UNTIL and table-level privileges | Role removed and its sessions terminated at revoke |
| Kubernetes | A RoleBinding to a ClusterRole, scoped to the namespace | RoleBinding removed at expiry |
Because every grant is a distinct, named object, you can audit it from your own side: list the
IK- permission sets in Identity Center, the login roles in Postgres, the RoleBindings in
a namespace, and compare them with the InsightKeys record.
The people in the loop
Machines are half the review. The other half is whether a person can be impersonated or can approve their own access.
- Sign-in comes from your identity provider — Okta, Entra ID, Google or Duo single sign-on — through OIDC, with your own MFA policy.
- Step-up is a second factor at the moment of risk: a built-in authenticator app (TOTP, RFC 6238, with replay protection) or a Duo push. An assertion lasts five minutes and can be used once. It is required at risk 55 and above by default, by flows that ask for it, for break-glass, and for approvals on flows that require approver MFA.
- Separation of duties: where a flow requires two approvers, neither may be the requester.
- Slack requests and approve or deny buttons are signature-verified.
The agents
InsightKeys uses agents to draft requests, narrow permissions, score risk, watch sessions and propose clean-ups. A review should ask what they are allowed to do on their own. Each governed agent runs at an autonomy level — L1 Draft, L2 Ask first, L3 Act and tell, L4 Act — set per organisation and capped by a deployment ceiling. Every action appears in an agent inbox with approve, reject or undo, and in the audit trail. The intake agent only drafts from your catalogue and never invents a resource; the scoper can only narrow inside an entitlement’s ceiling, never widen; and whatever an agent decides, the broker still applies its local policy.
What is not done yet
Gaps a reviewer should record
Independent penetration test: planned before the first external customer goes live; ask for its status. Packaging: the broker runs with docker run or Docker Compose today; CloudFormation, Terraform and Helm packaging is planned. Test coverage: the AWS drivers are tested against moto, an AWS API emulator; the PostgreSQL driver against a real database; the Kubernetes driver against its REST API shape. We do not claim large production deployments. Integrations: Google Cloud, Azure, MySQL, Snowflake, GitHub and others are planned, not available. Session recording for SSH and kubectl and passkey (WebAuthn) step-up are on the roadmap.
None of these is unusual for a young product, and each is better stated than discovered. A security review should record them as conditions, with dates, rather than as reasons to stop.
Running the review
Identify every credential that can change permissions, where it lives, and who could use it.
List what an attacker in the vendor could do. Check that a local control you own limits it.
In a test environment, block the broker’s outbound connection during a grant and confirm the grant still expires on time.
Set maximum duration, keep the forbidden actions, disable admin where not needed, test the pause switch.
Single sign-on, step-up, two-person approval, a requester trying to approve themselves.
List the objects the broker created in AWS, Postgres and Kubernetes and reconcile them with the record.
Penetration test, packaging, integrations: what, by when, and what you do until then.
A tool that grants access should never be the easiest way to get it.
Keep the granting credential in your network, bound it with a policy you own, make revocation independent of the vendor, and write down what is not finished yet.