Layne exists because sharing one company card with fifty vendors is a security hole. Here is exactly how we keep the blast radius of any incident at one vendor, one cap.
Card credentials are held in our card platform's PCI-DSS Level 1 environment and never touch our servers. Layne stores only the last four digits and a card reference. When you reveal a card in the app, the full number renders inside the platform's own secure frame: it never passes through or rests on a Layne server.
When an agent asks to spend API credits, our servers check the request against the agent's policy and a running spend ledger before answering. An enforcing agent is denied any request that would take its month's spend past its cap, a frozen agent is denied even in shadow mode, and no API key can change a policy. Card charges an agent makes are governed by your card and account caps today, not by the agent's policy.
Every vendor gets its own card with its own hard cap. A compromised or careless vendor can spend at most its own limit: never your balance, never another vendor's card.
Every cap is mirrored onto the card itself as a native spending limit at the card network. If Layne is unreachable, over-cap charges still decline and your caps hold at the network.
Traffic is served over TLS. Data at rest is encrypted (AES-256) by our infrastructure providers, and card data never reaches that storage in the first place.
Viewers see everything and change nothing. Sensitive actions (issuing cards, moving caps, funding) are written to an audit log with who, what, and when.
Layne cannot spend your balance: money only moves when a card you created is charged. Layne cannot exceed a cap you set: over-cap charges decline at the network. And Layne cannot see full card numbers: they never leave the PCI-DSS Level 1 environment that holds them.
Every statement on this page is verified against the running system before it ships. If it isn't here, we don't claim it.
Not yet claimed: SOC 2, SSO/SAML, managed KMS. We'll add each when it's true.