# First-impression review of inkog.io Inkog appears to be a static-analysis security scanner for AI-agent code, flagging agent-specific issues such as prompt injection, unsafe tool use, runaway loops, and missing oversight, then mapping findings to security and compliance frameworks. It is aimed at developers building agents and the security or compliance teams responsible for production deployments, from open-source evaluators to regulated enterprises. I would test it on a public or disposable repository, but I would not yet trust it with private production code because the public site gives conflicting accounts of what leaves the machine, makes an unsupported absolute accuracy claim, and does not state an auditable SOC 2 or sub-processor status. ## 1. The code-handling story contradicts itself at the point where trust matters most **Source URLs:** https://inkog.io/trust, https://inkog.io/verify, https://inkog.io/trust/privacy **Exact on-page quotes:** > “We don't secure your data because we never touch your data.” > “Source code is redacted locally before transmission. Only the sanitized logic graph is analyzed. API keys, credentials, and secrets stay on your machine.” > “Your code is processed and immediately forgotten.” The Privacy Policy table also labels “Source Code” / “Your actual code files” as “Collected? No.” **Comprehension/trust consequence:** These statements do not describe one unambiguous data flow. A first-time visitor cannot tell whether Inkog receives redacted source code, only a derived logic graph, or no code-derived payload at all. “We never touch your data” is especially hard to reconcile with cloud analysis and the separate statement that code is “processed.” For a security product asking to inspect a codebase, that uncertainty is a direct adoption blocker. The public site alone is not sufficient to determine which description is technically accurate. **Suggested rewrite:** > Your secrets stay local. The CLI converts your code into a sanitized logic graph and sends only that graph to EU-hosted, stateless analysis. Inkog retains no source code or logic graph; scan metadata such as file count, duration, and pattern matches is retained for 90 days. Use that wording only if it reflects the real architecture. If redacted source code is transmitted, say that plainly instead of saying that Inkog never touches the data. ## 2. “0% false-positive rate” is an absolute claim without public evidence sufficient to assess it **Source URLs:** https://docs.inkog.io/, https://inkog.io/report **Exact on-page quotes:** > “Audited on 500+ open-source agents with a 0% false-positive rate.” > “Each repo shallow-cloned and scanned with Inkog v1.1.0 using the comprehensive policy (all detectors, no confidence filtering). Results parsed and stored as structured JSON.” **Comprehension/trust consequence:** The site does not define the denominator for the false-positive claim, show a manual-validation protocol, or link to a labeled dataset that would let a visitor reproduce it. The report methodology describes how repositories were scanned, but not how every finding was adjudicated as true or false. An unexplained absolute claim is more likely to reduce confidence among security buyers than increase it, particularly when the methodology says there was “no confidence filtering.” The claim cannot be validated from the public site alone. **Suggested rewrite:** > In a manually reviewed benchmark of [N] findings across [M] repositories, Inkog achieved [X%] precision. See the labeled dataset, review protocol, and detector-level results. Publish those materials at the same link. If a validated figure is not available, remove the percentage and describe the feedback and suppression workflow instead. ## 3. The primary CTA promises a ZIP workflow that its destination does not show **Source URLs:** https://inkog.io/#scan-preview, https://app.inkog.io/scan **Exact on-page quotes:** > “Paste a GitHub URL or upload a zip. No install, no config. Here's what comes back.” > “Paste a public GitHub repo URL. Get a security report in 60 seconds.” **Comprehension/trust consequence:** After clicking the main scanning CTA, the first-time visitor sees one field for a public GitHub repository and no visible ZIP upload. Someone with a private repository or a ZIP reaches a dead end immediately after being told that the path requires “no install, no config.” This is a functional expectation mismatch, not a cosmetic one. **Suggested rewrite:** > Scan a public repository in 60 seconds—paste a GitHub URL. For private code, use the local CLI. ZIP upload is available after sign-in. If ZIP upload is not currently available, remove that promise. Use distinct CTAs such as “Scan a public repo” and “Scan private code locally.” ## 4. The site gives three different versions of the first CLI command **Source URLs:** https://inkog.io/, https://docs.inkog.io/ **Exact on-page quotes:** > “npm install -g @inkog-io/cli” > “inkog verify ./your-agent” > “Scan your agent code in seconds — no install needed:” > “npx -y @inkog-io/cli scan .” The cookie panel also displays “inkog verify --target inkog.io.” **Comprehension/trust consequence:** A developer cannot tell whether the canonical operation is `scan` or `verify`, whether `--target` is required, or whether installation is necessary. This creates avoidable copy-paste failures at the exact moment the visitor is evaluating how quickly the product works. **Suggested rewrite:** > Run your first scan: `npx -y @inkog-io/cli scan ./your-agent` Use that same command on the homepage, in the docs, and in decorative terminal examples. If `verify` is a supported alias or a different workflow, explain the distinction next to the first command rather than making visitors infer it. ## 5. The compliance message overstates what static analysis can conclude **Source URL:** https://inkog.io/ **Exact on-page quotes:** > “Every finding mapped to compliance” > “Inkog doesn't just find vulnerabilities — it tells you which regulation they violate and what to fix.” **Comprehension/trust consequence:** Mapping technical evidence to a potentially relevant article or control is useful; declaring that a finding “violate[s]” a regulation sounds like a legal conclusion about a system and its context. A static scan alone cannot establish every element of regulatory applicability or compliance. The wording may attract attention, but it creates credibility and legal-expectation risk with the regulated buyers the site targets. **Suggested rewrite:** > Every finding is mapped to potentially relevant EU AI Act, NIST AI RMF, ISO 42001, and OWASP controls for human review, with remediation guidance. These mappings support compliance work; they are not legal determinations. ## 6. The supported-scope numbers conflict, and “frameworks” and “integrations” are used interchangeably **Source URLs:** https://inkog.io/, https://inkog.io/verify **Exact on-page quotes:** > “Scan Microsoft, Google ADK, Python, LangChain, CrewAI, MCP servers, Skills and 20+ frameworks for agent-specific vulnerabilities — in 60 seconds.” > “ONE SCANNER FOR 15+ AGENT FRAMEWORKS. PYTHON CODE AND JSON WORKFLOWS.” > “View all 15+ supported integrations” **Comprehension/trust consequence:** A visitor cannot tell whether the product supports 15 or more than 20 frameworks, or whether the larger number includes languages, workflow formats, MCP servers, and Skills. The hero also mixes a company name, a language, frameworks, and artifact types in one list. That makes it unnecessarily difficult to answer the basic qualification question: “Will this scan my stack?” **Suggested rewrite:** > Scan AI-agent code across 15 supported frameworks—including LangChain, CrewAI, Google ADK, Microsoft AutoGen, and OpenAI Agents—plus MCP servers, Skills, Python code, and JSON workflows. Link “15 supported frameworks” to one maintained compatibility table, and report non-framework inputs separately. ## 7. The proof counters disagree on the first click **Source URLs:** https://inkog.io/, https://app.inkog.io/scan **Exact on-page quotes:** > “We scanned 500+ open-source AI agents. 85% had at least one vulnerability.” > “484 agents scanned” **Comprehension/trust consequence:** The public scanner shows a smaller total than the site-wide research claim. These may be different datasets or counters, but neither label explains the distinction. Because the “500+” figure anchors several credibility claims, an unexplained contradiction makes all of the proof numbers feel less reliable. **Suggested rewrite:** > 2026 research dataset: 500+ open-source repositories scanned. > Public scanner: 484 completed scans as of [date]. If they measure the same thing, use one synchronized counter. If they do not, label the population, date, and method every time. ## 8. The Free-versus-Deep compliance boundary is unclear **Source URLs:** https://inkog.io/, https://inkog.io/pricing **Exact on-page quotes:** > “Every finding mapped to compliance” > “One scanner across every tier. Upgrade when you need full compliance mapping and CI/CD integration.” > “OWASP LLM Top 10 mapping” > “EU AI Act + NIST compliance reports” **Comprehension/trust consequence:** The homepage makes compliance mapping sound universal, while Pricing says a visitor must upgrade for “full” mapping. The Free card lists OWASP mapping, and Deep lists EU AI Act and NIST reports, but the site does not explain the practical difference between a mapping and a report. A buyer cannot confidently predict what the free scan will actually return or what the $99 plan unlocks. **Suggested rewrite:** > Free: five scans per month, severity-ranked findings, and OWASP category labels in the web report. Deep: unlimited scans, downloadable EU AI Act and NIST reports, CI/CD gates, and Inkog Red. Define what “unlimited” applies to—user, organization, repository, or fair-use allowance—and use the same tier qualifiers wherever compliance is promoted. ## 9. The cookie interface blocks the evidence a visitor is trying to evaluate **Source URLs:** https://inkog.io/, https://inkog.io/pricing, https://inkog.io/about **Exact on-page quotes:** > “$ inkog verify --target inkog.io” > “✓ Analytics 1 (EU hosted) ✓ Cross-site none ✓ Data shared never” > “We use cookies to improve your experience.” > “Accept” / “Decline” **Comprehension/trust consequence:** At a 1272×720 desktop viewport, the large terminal-styled panel covers part of the homepage scan example, the pricing comparison columns, and the About-page story and mission cards. The first privacy decision also visually impersonates the product's scan output, which makes consent and product evidence compete for attention. The issue has a direct comprehension consequence because the panel hides the very proof, price, and company information needed for the decision. **Suggested rewrite:** > Cookie choices — We use one EU-hosted analytics provider and no cross-site advertising cookies. Accept analytics · Reject analytics · Manage choices Present this as a compact, conventional banner in reserved layout space. Keep the scan-terminal visual for product demonstrations, not consent. ## 10. The homepage introduces several products and narratives without explaining their relationship **Source URL:** https://inkog.io/ **Exact on-page quotes:** > “The security scanner for AI agents” > “Build secure AI agents with Claude, Cursor, and Claude Code” > “Agent Capability Surface” The footer separately lists “Inkog Verify,” “Inkog Red,” and “Inkog MCP.” **Comprehension/trust consequence:** The page moves from scanner positioning to an MCP workflow, compliance, a research report, and a capability/governance inventory before making the product family explicit. A first-time visitor has to infer that the main scanner is Verify, that MCP is another way to invoke it, and that Red is a separate adversarial-testing product. The concrete scan result appears later than several secondary stories, increasing the chance that a visitor stops before understanding the deliverable. **Suggested rewrite:** > Inkog Verify scans agent code. Inkog Red adversarially tests agents. Inkog MCP brings Verify into Claude, Cursor, and other coding assistants. Place that suite map immediately after the hero. Reorder the homepage to: core promise → sample report → ways to scan → code-handling and trust → pricing → secondary products → research. ## 11. Enterprise assurance language is not auditable from the public site **Source URLs:** https://inkog.io/verify, https://inkog.io/trust, https://inkog.io/trust/privacy, https://inkog.io/pricing **Exact on-page quotes:** > “SOC2 Ready” > “GDPR Compliant by Architecture” > “For the current list of specific sub-processors, contact legal@inkog.io.” > “Custom limits and dedicated support for regulated industries.” The Trust, Security, and Privacy pages say “Last updated: December 2025.” **Comprehension/trust consequence:** “SOC2 Ready” does not state whether Inkog has completed a SOC 2 audit, and “GDPR Compliant by Architecture” is not accompanied by a public DPA or a named sub-processor list. Requiring an email for basic vendor identities adds friction to security review. The public site therefore does not provide enough information to judge Inkog's actual SOC 2 status, contractual GDPR readiness, or cloud dependency risk—precisely the questions a regulated enterprise will ask before sharing code. **Suggested rewrite:** > SOC 2 Type II: [not certified / audit in progress, target date / certified, report available under NDA]. GDPR: DPA available here. EU processing region: [region]. Sub-processors: [vendor, purpose, data handled, region]. Last reviewed: [current date]. Replace “Ready” and “by Architecture” with verifiable statuses, dates, and links. ## 12. The About page offers personality where a code-security buyer needs identifiable accountability **Source URL:** https://inkog.io/about **Exact on-page quotes:** > “We spent the last decade building high-scale infrastructure.” > “Vibe” / “Builders, not marketers” > “We build for builders.” > “— Sam, Andreas & Ben, Founders” **Comprehension/trust consequence:** The story is personable, but only first names are shown and the experience claim is not tied to roles, companies, or verifiable profiles on the page. That is not enough accountability for a visitor considering whether to let the product analyze proprietary code. The tone also clashes with the Enterprise and regulated-industry positioning: those buyers need to know who operates the service and who is accountable for security. **Suggested rewrite:** > Built in Stockholm by [full name, role], [full name, role], and [full name, role], with [specific, verifiable experience]. Inkog AB operates the service. Review our security architecture, company details, and contact the security team at [address]. Keep the founder story, but add full names, roles, profile links, the operating entity, and a direct security contact.