sekura

What the Sekura LLM proxy never sees

Sekura routes LLM API calls through proxy.sekura.ai for billing and metering. Your source code, prompts, and findings never cross the proxy. Here is how the architecture works and why it matters for IP-sensitive teams.

Metering is not snooping.

The Sekura platform uses a dedicated LLM proxy at proxy.sekura.ai. The name sounds intrusive. It is not. The proxy's job is to count tokens and enforce billing limits. Your source code never crosses it.

What the proxy does

The proxy sits between our AI agents and the LLM provider APIs. When an agent calls a foundation model, that call routes through proxy.sekura.ai. The proxy captures four things and nothing else:

  1. The requesting agent identifier
  2. The number of input tokens sent to the model
  3. The number of output tokens returned by the model
  4. The model name, the timestamp, and the scan identifier

That is the complete list. The proxy does not log request bodies. It does not store prompts. It does not see your code, your findings, or your exploit chains.

Token counts are what we need for billing. They tell us how much compute a scan consumed. They are enough to generate an accurate invoice without touching the content that produced them. We designed it this way on purpose.

What never crosses the proxy

Your source code travels directly from the GitHub Actions runner to the LLM provider. It does not route through proxy.sekura.ai. The same is true for scan findings, exploit payloads, and any data your application exposes during dynamic probing.

I think this is the design decision that surprises most customers. The instinct is to assume a proxy sees everything it touches. Ours sees almost nothing. We separated the metering concern from the data concern because they belong in different trust zones.

The categories of data that never touch the proxy:

  1. Source files checked out by the GitHub Actions runner
  2. Agent prompts and the full LLM responses, including exploit synthesis output
  3. Scan findings and proof-of-exploit artifacts
  4. Runtime application data captured during dynamic probing phases

The LLM provider receives the actual API calls with your code in the payload. We receive only token counts. Those are different parties, different agreements, and different data.

How the call flow works

The sequence below shows where proxy.sekura.ai sits relative to your code and the LLM provider.

sequenceDiagram participant Runner as GitHub Actions Runner participant Agent as Sekura Agent participant Proxy as proxy.sekura.ai participant LLM as LLM Provider API Runner->>Agent: Starts scan (source checkout in local context) Agent->>Proxy: POST /meter/start (agent_id, model, scan_id) Proxy-->>Agent: Authorization token + request_id Agent->>LLM: API call (auth token in header, source code in body) LLM-->>Agent: Model response (findings, exploit candidates) Agent->>Proxy: POST /meter/complete (request_id, input_tokens, output_tokens) Proxy-->>Agent: Acknowledgement Agent->>Runner: Writes findings to local runner context

The proxy sees two lightweight metadata messages per LLM call. The LLM provider sees the full API call, including your code. Your findings stay inside the runner after the response returns. They are never sent back through the proxy.

The separation is structural, not a policy setting you have to configure. There is no option to route source code through the proxy because the proxy was never built to carry it.

The metering log schema

For teams that need to audit what the proxy stores, here is the exact schema of a metering record:

{
  "request_id":     "req_01j7z3m2k9x5w8p4n6q",
  "agent_id":       "sast-agent-v3",
  "model":          "claude-sonnet-5",
  "timestamp":      "2026-07-03T08:14:22Z",
  "input_tokens":   4812,
  "output_tokens":  389,
  "latency_ms":     1240,
  "scan_id":        "scan_sekura_8k3p7",
  "customer_id":    "cust_a9f7e2"
}

No prompt text. No file paths. No code snippets. The schema is intentionally narrow. Every field serves billing, rate limiting, or latency monitoring. Nothing else fit the schema and stayed in the schema.

Why this matters for IP-sensitive teams

I believe the cleanest architecture for sensitive workloads keeps data flows minimal. Every intermediate service is a place where data can be logged, breached, or compelled by legal process. Removing a hop removes that exposure surface.

The LLM providers we use operate under data processing agreements that, in most enterprise configurations, explicitly prohibit training on customer content. That agreement is between you and the provider. The proxy does not change it, alter it, or introduce a new party into the chain.

For teams running Sekura in enterprise distribution mode, the architecture is stricter still. The agents run entirely inside your firewall. The proxy.sekura.ai endpoint is replaced by an internal metering service on your own network. No data, no metadata, no request counts leave your perimeter during a scan.

You can verify the proxy's behavior in the Sekura dashboard. Every token count for every scan is visible, per agent, per model call. You will not find source code in those records. It was never there to find.

Security claims are easy to make. The architecture is what makes them checkable. Read how Sekura handles your source code end-to-end at /product/.