What we defend against. What we don't.
Most security marketing dodges this question. We won't. Below is the honest list of what Ledgerline is designed to make harder, and an equally honest list of what it doesn't promise to fix.
Threats Ledgerline is designed to mitigate
Unauthorized action by a compromised or rogue agent
An agent — or the operator running it — attempts an action outside the scope it was delegated. Defense: every action is checked against the policies attached to the identity and its ancestors before it executes. A jailbroken agent that is told to wire $10M to a new merchant still has to clear the policy check. If the policy doesn't permit a wire, or doesn't permit a new merchant, the action is denied.
Runaway spend
An agent (correctly authorized for a class of action) ends up consuming far more than expected — through a loop, a misconfiguration, or a prompt-injected instruction to "buy as many as possible." Defense: budget reservation at decision time, hard caps per period, and instant kill-switch on the issuing card.
Loss of provenance
Six months later, no one can answer who authorized a specific action. Defense: every action writes an audit row pinned to the full identity chain at decision time. The chain is preserved even if individual identities are later revoked or renamed.
Tampering with the audit trail
An attacker — or an insider — wants to remove evidence of an action. Defense: the audit log is hash-chained. Removing or altering any row invalidates every hash from that point forward. The chain integrity check is a single API call.
Slow revocation
An employee leaves, an agent is decommissioned, or a contract ends — and there's a window where the credential is still active. Defense: revoking an identity invalidates every action attempted by it or its descendants on the next decision check. Any virtual cards it issued are simultaneously frozen.
Replay of a stale or borrowed transaction
An attacker captures a previous authorized request and replays it later. Defense: every authorization carries a transaction-bound identifier; the audit log surfaces duplicate identifiers, and the policy engine can require freshness checks for high-value actions.
Threats Ledgerline does not claim to mitigate
The LLM saying something wrong
If your agent generates incorrect, biased, or harmful content, that's outside our scope. Use a guardrail or content-safety library. We govern actions, not utterances.
Prompt injection that stays within authority
If a malicious prompt convinces your agent to do something it was already authorized to do — refund the wrong customer, send the wrong invoice — we won't catch it. We can only deny actions outside policy. This is why narrow policies and per-task budgets matter.
Compromise of the Ledgerline control plane itself
If our control plane is breached, an attacker could potentially edit policies or reset budgets. Defenses are the standard ones: encryption at rest and in transit, role-based access for human operators of the control plane, audit of admin actions, and (for self-hosted deployments) network isolation. The audit log itself remains hash-chained — a tamper attempt produces a verifiable break.
Model exfiltration and IP theft
If your agent leaks training data, weights, or proprietary prompts to an outside party, Ledgerline does not see prompt content and cannot detect it. Use DLP and egress controls.
Supply-chain attacks on dependencies
If a library your agent depends on is compromised, the malicious code may operate within authorized policy bounds. We constrain what the agent can attempt, not how the agent's runtime is composed.
Network-level attacks
DDoS, BGP hijack, TLS-stripping at intermediaries — these are concerns of your network and CDN, not of an action-authorization layer. Ledgerline runs behind the same protections you run other production services behind.
Trust boundaries we explicitly assume
- The Ledgerline control plane is operated honestly. Audit logs are evidence to third parties that we did not selectively delete entries; chain verification is the proof.
- The card network and identity verification layer (Lithic, in production today) is operated honestly.
- Your operators authenticate to the control plane through your existing IdP. Ledgerline does not store passwords.
- Time is approximately monotonic. Severe clock skew across the system can create unusual budget-reservation behavior; we assume NTP works.
Reporting a vulnerability
If you have found a security issue, please email [email protected]. We will respond within two business days. See /security/ for our coordinated disclosure policy.