Security & Trust

How we protect your data and your agents. Last updated: July 2026.

Veragent is an EU-native AI agent governance platform, built security- and privacy-first from the ground up. This page describes the measures we use to protect your data and the agents you connect, and it is the single home for our security posture. We describe what we actually do — we don't claim certifications we don't yet hold, and where a claim has a limit, the limit is on this page next to the claim.

Where Veragent enforces

Veragent governs at the action boundary: your agent calls authorize()before it acts, and the decision is made with the action's own meaning in hand. That is what a wire-level gateway cannot see. A proxy can observe that a request went to an API; it cannot know that the request moves €40,000, that this agent has already moved €35,000 today, or that this counterparty needs two approvers. Because the decision point understands the action, it can carry budgets that meter a real quantity, approval loops with quorum and delegation, a trust score that moves with behaviour, and a sealed record of who decided what.

The limit of that, stated plainly: Veragent governs the agents you instrument. An agent that never calls authorize() is not governed by Veragent and is invisible to it. We do not scan your network, enumerate your workloads, or discover agents you have not told us about — this is not a discovery or shadow-AI tool, and nothing on this page should be read as claiming that coverage. Veragent composes beside a gateway or an identity fabric; it does not replace either.

One consequence worth naming: budget figures are self-reported by the instrumented agent. When a budget meters an amount, that amount arrives in the context your agent sends. Veragent enforces the limit faithfully against what it is told; it does not independently observe the underlying transaction.

Data residency & hosting

  • EU-onlyYour data is stored in the European Union — our database runs in Ireland (eu-west-1), and the application's serverless functions are pinned to Dublin (eu-west-1), co-located with the database.
  • GDPR-firstVeragent is operated by Veragent B.V., registered in the Netherlands, and built to comply with the GDPR and the Dutch Implementation Act.

Authentication & access control

  • Two-factor authenticationTOTP-based 2FA, enforced for administrators.
  • Encrypted sessionsSessions are held in encrypted, HttpOnly cookies — never in browser storage.
  • Step-up elevationSensitive actions — deleting or rotating API keys, billing changes, granting roles — require a fresh 2FA challenge, even within an active session.
  • Single sign-onMicrosoft Entra ID (OAuth) and SAML 2.0.
  • Anomaly detectionNew-device and unusual sign-in detection, with role-based access and least-privilege defaults.
  • Per-key IP allowlistsAn API key can be pinned to the networks it may be used from. A call from outside that list is refused with a 401 — an authentication failure, which never enters the governance record and creates no decision. A key with no allowlist behaves identically to one that never had the feature.
  • Rotation without an outageRotating a key issues a successor immediately while the predecessor keeps working for a bounded overlap (24 hours by default, 168 at most), so there is no window where your agents are locked out. The predecessor's expiry becomes the earlier of its existing expiry and the overlap end — rotation can only shorten a key's life, never extend it.

Data protection

  • Hashed credentialsAPI keys are never stored in plaintext — only as SHA-256 hashes. A key is shown once at creation and cannot be retrieved afterward.
  • Signed webhooksOutbound webhook payloads are HMAC-signed and timestamped, so you can verify they came from Veragent and reject replays.
  • Encryption in transitAll traffic is encrypted over TLS, with HSTS enforced.
  • Tenant isolationSeparation between organisations is enforced at the database layer with row-level security — one organisation can never read another's data.
  • No AI subprocessorsYour data is never sent to any LLM or external AI service. Veragent's processing is conventional software — there is no AI vendor in your data's path, and our GDPR data export discloses the full subprocessor list.

Key custody

  • Secrets are not in the repositoryNo environment file is tracked in version control. Platform secrets live in our hosting provider's encrypted environment store and are injected at runtime.
  • One reader for the database credentialThe privileged database credential is reached through a single accessor, pinned by a test that walks the source tree and fails if any other product file reads it.
  • The signing key checks itselfThe audit signing key refuses to sign unless its public half matches the key published in our signing-key registry. A half-finished rotation stops signing rather than producing signatures nobody can verify.
  • Scheduled jobs fail closedEvery scheduled endpoint authenticates with its own shared secret and refuses to run at all when that secret is absent, rather than running unauthenticated.

Application & infrastructure security

  • Deny-by-default authorizationEvery API endpoint requires an authenticated, 2FA-verified session unless explicitly public, and re-checks authorization server-side on every request. The public list is an explicit allowlist held in one place; a test enumerates the routes and fails on any endpoint that becomes reachable without a gate.
  • No accidentally-public compliance endpointEvery compliance route was walked in source: the only one reachable without a session is the endpoint that publishes our audit verification keys, which is public by definition. Evidence packs, integrity reports, receipts, timelines and seal exports all require an authenticated administrator.
  • SSRF protectionCustomer-supplied webhook URLs are validated against private and internal address ranges.
  • Rate limitingDistributed rate limiting protects authentication and ingestion endpoints from abuse.
  • Hardened headersA Content Security Policy and a full set of security response headers are applied across the application.
  • Dependency hygieneWe track and promptly patch known vulnerabilities in our dependencies.

The audit trail, and what it proves

Organisation activity is recorded in an append-only, tamper-evident audit log. This section states what that buys you and, immediately after, what it does not.

  • Append-only at the databaseUPDATE and DELETE are revoked from every application role. Records can be removed only by a recorded, organisation-scoped purge — for an erasure request — and that door cannot express the deletion of an individual record.
  • Sealed hourly, chainedRecords are sealed in hourly windows, each seal chaining to the one before it, so a gap or a reordering is detectable rather than silent.
  • Signed with a published keyEach seal carries an Ed25519 signature made with a key held outside the database. The public half is published at /.well-known/veragent-audit-signing-keys.
  • Verifiable without usWe publish a verifier script that checks the chain and the signatures offline. It needs the export and the published key — no Veragent systems, credentials or cooperation.
  • Anchored to a public logAudit chain heads are additionally committed to a public transparency log (Sigstore Rekor). Once an anchored head covers a period, retroactive rewriting of that history — including by us — is independently detectable from the anchor proofs.

What this does not prove. These are the limits of the claim, and they ship inside the signed artifacts themselves, not only here:

  • Integrity since sealing, not honesty at writingSignatures and anchors prove these records have not changed since they were sealed and signed. They do not prove the records could not have been written falsely in the first place: the signing key is operated by the same environment that writes the records. Independent verification covers integrity since sealing; the honesty of the original record is Veragent's attestation.
  • Integrity of what was recorded, not completeness of recordingSeals attest the integrity of what was recorded, never the completeness of recording. A record that failed to be written — a crashed process, a dropped connection, an outage in the recording path — leaves no trace in these artifacts, only in operational logs.
  • Detection, not preventionThis is tamper-evidence, not tamper-proofing: alteration of sealed records is detected, not prevented.

Verify it yourself. The claim above is concrete: the verifier script is published, together with three frozen artifacts from our demonstration organisation — real rows, real seals, real signatures over seeded demonstration activity. Each snapshot carries its generation date, and a snapshot keeps verifying after key rotation: retired signing keys stay in the published registry.

  • The verifierverify-audit-seals.mjs — one file, stock Node.js 18+, no packages. It imports nothing from our codebase; every check is reimplemented from the documented byte formats, so you can read exactly what it proves — or reimplement it in any language with SHA-256 and Ed25519.
  • An oversight receiptreceipt.json — one decision: a trade held for human sign-off by the rule "large trades require desk quorum" and allowed by a 2-of-2 quorum, citing the seal that covers it.
  • A signed timelinetimeline.json — eight hours of governance activity around that trade: the escalation, an org-wide pause, break-glass grants issued, used, revoked and expired, and four enforced denials — every entry citing its seal.
  • A seal exportseal-export.json — the organisation's full chain: every seal, every signature, and the public-log anchor proofs, verifiable end to end.
curl -O https://www.veragent.io/evidence/verify-audit-seals.mjs
curl -O https://www.veragent.io/evidence/2026-07-28/receipt.json
curl -o keys.json https://www.veragent.io/.well-known/veragent-audit-signing-keys
node verify-audit-seals.mjs receipt.json --keys keys.json

Fetch the keys yourself from the well-known address — the point is that you do not take an artifact's word for its own key. A pass proves the content is unchanged since it was sealed and signed; it does not prove honesty at writing. The limits above apply to these artifacts exactly as stated, and each one repeats them in its own signed bytes. Our test suite runs the published verifier against these published files and fails the moment they stop verifying.

When the SDK cannot reach us

What happens when things go wrong is part of the contract, not an afterthought. There are three layers and they fail differently on purpose — the same words ship in the published SDK READMEs.

  • 1 · Enforcement is off by defaultA client constructed without enforcement enabled never makes an authorization call at all — authorize() returns allowed immediately, and adapters run every tool call. Out of the box nothing is ever blocked, so you can wire the call through your codebase before you are ready to enforce. Until you opt in there is no enforcement guarantee, by design.
  • 2 · With enforcement on, an unreachable Veragent fails safeIf the call cannot reach us, the SDK returns not allowed with an error status — it never fabricates an approval. If you honor that verdict (the enforcing adapters do), an outage means the guarded action does not proceed.
  • 3 · Escalation timeouts are decided by your policyWhen an action escalates to a human and nobody answers by the deadline, the matched rule's own fail mode decides — fail_closed resolves denied, fail_open resolves allowed. That is your configuration, not an SDK default.

The three not-allowed outcomes stay distinguishable: denied is a real policy or human no, timed_out is an escalation nobody answered, and error is an answer we could not deliver. Authorization failures are always legible in the returned decision — never silently swallowed.

Privacy & your rights

  • GDPR rights, self-serviceRequest a copy of your data (Article 15) or its erasure (Article 17) directly from your account.
  • Data minimizationWe collect only what's needed to run the platform — see our Privacy Policy for details.
  • Data Processing AgreementA DPA is available to customers on request.

Compliance & evidence

Veragent produces an auditor-ready evidence pack — a date-ranged record of the policy-enforcement decisions and human-oversight actions taken across your organisation. It's designed to support EU AI Act readiness by demonstrating meaningful oversight and control over the autonomous agents you run.

Specifically, the evidence pack supports a deployer's EU AI Act Article 12 record-keeping obligations— it supplies the evidence, and does not by itself make any organisation "Article 12 compliant". It is a component of the answer, not the answer: Article 12 is discharged by your organisation's practice, of which the record is one part. What Veragent discharges is the keeping of the record — automatically, in a form that survives scrutiny. What it supports, and cannot do for you, is the governing: deciding which actions matter, who reviews them, and what your organisation does when the record shows something it should not.

Each section maps to a limb of Article 12(2):

  • Art. 12(2)(a)The enforcement record, violations and escalations — logs that help identify situations where an agent may present a risk (Art. 79(1)) or a substantial modification.
  • Art. 12(2)(b)The pack itself and its retention line — facilitating the post-market monitoring required by Article 72.
  • Art. 12(2)(c)The human-oversight record — evidence of monitoring the system's operation, per the deployer duties in Article 26(5).

On timing.The EU's Digital Omnibus — in force since July 2026 — moved the Annex III high-risk obligations to 2 December 2027, the Article 12 logging duties and the retention duties in Articles 19 and 26 among them. Two things it did not move: the Article 50 transparency duties and the Article 4 AI-literacy duty. A deferral is not a repeal — the duties are unchanged and the date is fixed. We don't think a date is a reason to start the record later: an organisation that begins keeping the record when the obligation lands has no history to show for the period before it. Veragent's records are compliant by default — append-only, sealed, with a 180-day retention floor on every tier — so readiness costs nothing to have early. That is a posture, not a countdown.

Attestations

Veragent does not hold a SOC 2 attestation, and no audit is under way. We would rather say that than describe a process we have not started. An attestation is a statement by an auditor about our controls, and we do not have one.

What exists instead is narrower but stronger in one specific respect: it does not require trusting us. The audit chain described above is signed with a published key and anchored in a public transparency log, and our verifier checks it offline. A third party can confirm that your records have not been altered since they were sealed without asking Veragent for anything, and without taking our word for the result. That is a different kind of assurance from an attestation, and it does not substitute for one where a customer or a regulator specifically requires SOC 2.

Responsible disclosure

We welcome reports from security researchers. If you believe you've found a vulnerability, please email security@veragent.io. We'll acknowledge your report, work with you to validate and resolve the issue, and ask that you give us reasonable time to do so before any public disclosure.