Svalin

Go · React · GCP · Terraform

Svalin logs, governs and audits what AI coding agents (Cursor, Claude Code, Gemini) do. It ingests 1M+ events per month on minimal GCP tiers with sub-150ms queries.

Genesis

As early as February 2026, AI was spreading through tech companies very fast. Investors and C-levels were putting a lot of pressure on engineering teams to adopt AI coding tools such as Claude, Cursor and Gemini.

The switch was so fast that most InfoSec teams had to adapt quickly to potential threats. Those AI tools initially had very few governance features, especially for compliance and regulated industries.

As an engineering lead, I believed strongly in engineers embracing the AI wave, but I was also concerned about the misuse of customer information and information leaks. I decided to track my own AI activity first, using a simple agent running in the background and intercepting AI interactions from coding agents running in terminals.

I founded the Svalin concept and was its founder/builder: I designed the solution and built the MVP.

Architecture choices

Svalin was primarily an on-laptop agent running in the background, which logged MCP and AI operations on the local machine. I chose a local agent so InfoSec teams could be 100% aware of any attempt to bypass the rules, as early versions of AI coding agents allowed developers to overwrite LLM proxy URLs.

The Svalin local agent easily answered several questions that LLM proxies at that time could not answer accurately:

• Which files were read or modified by an AI coding agent
• In which context an AI agent wrote a piece of code
• The full conversation flow, with tamper-evident proof

Finding which AI conversations touched a repository or a file

Running in production

Svalin ran in production on 12 laptops in parallel. It ingested more than 1M events per month. The InfoSec team got a full inventory of the tools accessing the company code base, and adjusted their AI policy as they discovered software that was not planned in the initial policies and technically not fully allowed.

Inventory of AI tools, including the ones not covered by the policy

The Svalin local agent had a very small footprint: developers using it reported no noticeable latency and no memory leak. A benchmark run in September 2026 on an Apple M1 Max showed:

• Memory: 25.5MB at idle, never above 34.8MB, and back to its baseline after AI sessions closed
• CPU: 1% of one core at idle, 0.10% of the whole machine
• Hook latency: 12ms per AI agent tool call, of which only 0.9ms was policy evaluation
• LLM proxy overhead: around 76ms, 1.5 to 4% of a typical call; 98.9% of the wait was the provider generating its first token
• Battery: about 0.9 minutes per full charge
• Binary: a single 19MB file

The benchmark also led to three optimizations: the hook wrapper went from 43ms to 12ms (−72%) by removing a Python step, idle CPU dropped by 66% by moving file watching to events instead of a timer, and caching local software versions reduced the battery cost from 4.2 to 0.9 minutes per charge.

On the Svalin platform side, the local agent sent events in batches (up to 50 events every 5 seconds), so each laptop sent at most around 12 ingestion requests per minute, no matter how many operations the AI agents performed. The ingestion endpoint answered in [TODO: ingestion p95, e.g. 40ms] at p95, and dashboard queries stayed under 150ms.

Event ingestion also reported a 99.9% ingestion rate; a few events were discarded due to high load on the database during the early days of the pilot.

Design

architecture-beta
    group frontend(cloud)[Frontend]
    group backend(cloud)[Backend]
    group laptop(cloud)[Laptop]

    service web(internet)[platform] in frontend
    service api(server)[API Server] in backend
    service kms(cloud)[Google Cloud KMS] in backend
    service agent(disk)[Local Agent] in laptop
    service auth(server)[Auth Service] in backend
    service db(database)[Database] in backend

    web:R --> L:api
    agent:B --> T:api
    kms:T --> B:api
    auth:R --> T:db
    api:B --> T:db

The Svalin platform was designed for idea validation, with a very low cost bar.

GCP was the easiest infrastructure for me to set up, using Cloud Run and a Cloud SQL database. The goal was to handle ingestion quickly and not over-engineer the solution before validating the idea and the technical solution.

While the Cloud SQL database was enough, it required some optimization and heavy indexing to support metrics and the platform's load. If we needed to scale up, the plan was to move cold data, not needed for complex queries, to a different storage.

Security

Svalin data could carry critical information, and the platform was designed as multi-tenant.

Each "organization" or "tenant" had an encryption key created automatically, which encrypted at rest any critical information such as prompts and API responses.

Only the metadata needed for complex queries was not encrypted, to allow easy navigation.

Every event logged by the local agent was linked to the previous one with a SHA-256 chain hash. If an event was removed or modified, the chain broke, which made the full conversation flow tamper-evident. The local agent was authenticated with a local certificate generated during onboarding, and it signed every request sent to the platform.

Security was also a very important point during development. The full CI/CD pipeline was designed to discover potential security issues early, before deploying the local agent to laptops. On every change to the local agent, and every week to catch new CVEs, it ran GitLeaks for secrets, gosec for static analysis, govulncheck and Trivy for vulnerable dependencies, go vet and staticcheck, and Svalin-specific security tests (for example, that the chain hash is never broken, or that API keys are never passed to commands run by an AI agent). Each release of the local agent was scanned again with govulncheck and Grype, shipped with an SBOM, signed with cosign, and signed and notarized by Apple for macOS. Dependabot handled security updates, and I used OWASP ZAP to pentest both the local agent and the platform.

Local Agent

The Svalin local agent embedded a policy engine, which was updated automatically from the platform and centrally managed. The local engine handled alerting and filtering in real time for every operation AI agents performed on the laptop, with little latency.

An alert raised by the local policy engine

The local agent's role was also to resolve the conversation flow based on the Process ID. It was able to detect sub-agent conversations and every operation, and to reconstruct the full conversation on the laptop's terminal. It assigned a custom conversation ID and a timestamp to every operation, which were then sent to the platform for ingestion.

A conversation rebuilt step by step

The local agent also embedded a small UI giving the developer full visibility of the policies enforced and the events logged, as well as which messages were decrypted by the InfoSec team when verifying an incident.

The local agent UI, showing the policy in use

Why it ended

Svalin ended in September 2026. The big players moved fast on compliance: they added stronger safeguards for companies and compliance endpoints, which covered a large part of what Svalin offered. The traction was also not strong enough for me to move fully on this project. A co-founder would probably have helped too.

What I'd do differently

Svalin made me realise how important it is to feel the traction before building anything. Having a couple of design partners before even building an MVP would have been the smart way.

Technically, I think Svalin was a success: a cheap MVP that worked at scale.