Every connector you add is a copy of your credentials in someone else's cloud¶
There is a form of technical debt that never shows up in a sprint. It accumulates in the vendor settings pages of the tools a company adopts, one OAuth grant at a time.
A compliance platform is the worst offender, because it wants to see everything. Your cloud accounts, to prove encryption is on. Your identity provider, to prove MFA is enforced. Your source control, to prove reviews happen. Your ticketing system, your HR system, your endpoint manager. The pitch calls this coverage. Each item on the list is a standing credential, issued by you, stored by them, valid until someone remembers to revoke it.
The shape of the risk¶
Three properties make this worse than it looks.
The credentials are long-lived. A connector that has to run nightly cannot use a token that expires in an hour, so it holds one that lasts months, or a service account that lasts forever.
They are concentrated. One vendor, one database, a hundred customers' keys. That is the kind of target that attracts patient attackers, and the compliance vendor's own security is now a dependency of yours, whether or not it appears in your risk register.
And they are over-scoped. Connectors are written once for all customers, so they request the union of every permission any customer's use case needed. Read-only in the marketing copy often means broad read across the whole account in the token.
Your security team has probably spent years pushing in the opposite direction: short-lived credentials, least privilege, no standing access for third parties. A compliance tool that asks for the connector library is asking them to make an exception large enough to fit a product through.
What changed¶
The reason the connector library existed was that the vendor's software needed to do the reading. That is no longer true. Your own AI, running on your side, can read your environment through the tools it already has: the cloud CLI it is authorised for, the identity provider API with the role you gave it, the repository it can already see. The access is yours, scoped by you, revocable by you, and it never leaves your side.
That is how Kanonik works. The agent does the discovery. It looks at what is actually deployed, drafts the control, finds the evidence, and proposes a record. Kanonik receives the proposal, not the credentials that produced it. Our verifier checks it. Someone on your team accepts it with a single-use signed click. Then it lands in the typed record, with a reference to where the evidence lives rather than a copy of the evidence itself.
We hold no credentials to any of your systems. There is no Kanonik-AWS connector, no Kanonik-Okta app, no Kanonik GitHub installation. The architecture does not have a place to put them.
Saying what we do hold¶
Honesty on this point is the whole argument, so here is the list. Kanonik holds your compliance record, encrypted at rest with a key that belongs to your tenant and is wrapped by a key that never leaves our vault. It holds the identities of your team members and their roles. It holds billing details through our payment processor, which never shows us the card number. That is the inventory. None of it opens a door into your environment.
Least privilege as a document, not a promise¶
Every skill we ship, the instruction set that turns your model into a compliance worker for a specific task, comes with a file that declares the minimum access that task needs, per source system. Read-only is the default. Anything that writes is opt-in, justified in writing, and switched on by your tenant admin. Your security team can read the declaration before the agent runs, and hold us to it afterwards.
The question to ask a compliance vendor is not how many integrations they have. It is what they are holding on your behalf, and what happens to it the day they have an incident.
Kanonik is new-gen GRC for teams that can't afford the GRC monsters and shouldn't have to. Try Kanonik free for 14 days at kanonik.ai.