We built PostQKey because data visibility was the gap in every security stack we touched.
Ann Arbor, MI. Founded 2024. Bootstrapped. Two engineers with a data governance problem that SIEM tools, DLP, and CSPM all missed.
The one finding that started everything.
Viktor spent six years at fintech companies building the data infrastructure that security teams then had to govern. In 2024, during a penetration test at his last employer, a tester surfaced something the security stack had missed for months: a Snowflake data share created by a data engineering team to serve a partner integration. The partner had been offboarded. The share had no expiry. It was still active, still pointing at the customer PII schema, still readable by the former partner's account.
The share was not visible in the SIEM because no alert was ever configured for it. CSPM did not flag it because the Snowflake account configuration looked fine. DLP was not watching intra-cloud sharing at the data warehouse layer. The finding came from a human running a manual check on a quarterly schedule.
PostQKey was built to make that finding automatic, not annual. Discovery of every active share, classification of what is inside, mapping of who can reach it, exposure score surfaced in a finding list your team can work through that day, not after the next pentest.
The people behind PostQKey.
Viktor Petrov
CEO and Founder
Viktor spent six years building data pipelines and access control systems at fintech companies. He has debugged Snowflake RBAC edge cases at 2am and traced customer PII to cloud locations nobody remembered creating. That experience is why PostQKey exists.
Before PostQKey, Viktor held data infrastructure and security engineering roles at two fintech companies, where he owned schema governance, IAM access policy, and incident response for data exposures. He has been on both ends of the access review: writing the policies and then auditing them a year later to find out how wrong they were. He writes about DSPM, data classification, and the gap between what access control systems say and what they actually permit, on the PostQKey blog.
LinkedInPostQKey is a small, growing team of engineers based in Ann Arbor. We are independently funded and not currently hiring.
Three principles we do not compromise on.
No agents. No data storage.
PostQKey reads metadata and samples data fields for classification. It does not store the underlying records you connected. Revoke the IAM role or OAuth token and PostQKey loses all access immediately. Classification results and schema snapshots remain in your account history. The raw data never leaves your environment. This is not a marketing claim about "security by design." It is a constraint we built into the architecture from the start, because we would not accept a DSPM tool that stored our data either.
Read-only by design.
Every connector is built with minimum necessary permissions. PostQKey cannot write to, modify, or delete anything in your data stores. We request List and Get. Nothing else. The permission scope is documented and verifiable before you grant access.
Findings you can act on.
We built the tool we wanted to use, not the tool that looks good in a compliance audit slideshow. Every finding includes: the specific asset, the specific risk, the specific access path, and a recommended action. Nothing in the finding list exists just to inflate the number.
Talk to Viktor directly.
Questions about PostQKey, a specific connector, or a custom enterprise plan? Viktor responds to every message.
301 East Liberty Street, Suite 500, Ann Arbor, MI 48104