Security
You are trusting us with records
that outlive portals.
This page explains the technical and operational safeguards behind Arrota: how access is controlled, records are protected, sensitive actions are logged, and private information stays scoped.
The boundary
What Arrota protects.
Record content
The information an issuer places in a record, the supporting evidence and its lifecycle history.
Personal data
Names, identifiers, contact details and other information required to operate the service.
Access & activity history
Who performed sensitive actions, what changed, and when.
Access & identity
Access is verified. Authority is scoped.
Signing in is the smallest part of access. What an account can do depends on who it belongs to, which organisation it is attached to, and whether the action is one Arrota treats as sensitive.
People
- Enforced password requirements through the auth policy
- Email verification before records can be used
- Multi-factor authentication
- Failed-sign-in lockout protection
- Session management with signed, HTTP-only cookies
Organisations
- Issuers are reviewed before they are activated
- Role-based access: super admin, admin and member scopes
- Verified email domains gate who can be issued records
- Team membership is tied to authenticated accounts
Operators
- Platform operators sign in on a separate administrative host
- Operator accounts use email OTP only, not passwords
- Audited, read-only support lookup for authorised operators
- Destructive actions require fresh verification
Sensitive actions such as disabling share links, exporting data or changing record state require the session to have signed in recently; otherwise Arrota asks for fresh authentication before the action runs.
Visibility & minimum access
Access is reviewed. Visibility is scoped.
Public
Public credential verification exposes only approved public information, and never the holder’s private record.
Private sharing
The holder determines which private records are shared, and for how long.
Formal verification
Structured verification follows holder authorisation and the issuer’s disclosure rules.
Organisation access
Organisation activity is associated with authenticated team members and their roles.
The principle throughout: knowing a public record identifier must not grant access to anything private.
Data protection
Private by default.
Documents are never placed on public URLs. Access to private data runs through database policies, short-lived credentials and scoped service roles rather than trust in the client.
Storage
Documents live in private object storage. There is no public document bucket; files are reached only through short-lived signed links issued to an authorised session.
Database
Row-level security policies decide which rows a session can read or change. The service role is scoped and not exposed to clients.
Keys and tokens
Issuer signing keys are stored encrypted, and private share links and developer API keys are held as hashes rather than raw values.
Paths that do not cross
Uploaded files land in a separate quarantine path and only move to the private document store after a clean scan verdict. Storage encryption at rest is provided by our infrastructure providers.
Record integrity
The record is the unit of protection.
Arrota protects record integrity structurally. A cryptographic signature supports origin and integrity; it does not independently prove that every real-world fact in the record is correct.
- SHA-256 fingerprints
- Every document’s hash is recorded, so the bytes a verifier’s link points at are the bytes that were issued.
- Digital signatures
- Eligible signed records carry a signature recorded at issuance.
- Corrections, not overwrites
- A correction changes the current state while the previous value remains recorded.
- Supersession and revocation
- Replaced and withdrawn records stay connected to their history instead of disappearing.
- Attributed issuance
- Records name the organisation that issued them and the account that acted.
- Visible lifecycle
- The current state is shown beside the events that produced it.
File upload security
Files enter through a guarded path.
An uploaded document is untrusted until a scanner has said otherwise. Uploads land in a private quarantine first, and only a clean verdict releases them into the record.
Quarantine before anything else
Uploads are written to a private quarantine store under an opaque path, never straight into the document store. If the scan step cannot run, the file stays quarantined and the upload fails closed.
Scanned by actual bytes
A ClamAV scanner receives the file bytes themselves over a restricted local connection. Only a clean verdict from that scan releases a file; scanner errors and timeouts keep it quarantined.
Reputation is advisory
An optional VirusTotal lookup of the file’s SHA-256 hash runs before the scan and can block a known-bad file, but it can never release one. Only a ClamAV clean verdict releases a file, and document bytes are not sent to VirusTotal.
Controlled retries
Interrupted scans resume through a single-use token bound to the same uploader, the same purpose and the same file bytes, and a clean verdict expires rather than living forever.
Application & infrastructure
Protection beyond the record.
Browser-facing hardening
Content Security Policy with per-request nonces, HSTS, clickjacking protection and strict referrer policy.
Server-side authorisation
Access decisions are made server-side on every request, backed by database row-level security.
Rate limiting
Authentication, uploads, verification and public surfaces each run through their own rate-limit buckets, failing closed.
Outbound calls are checked
Webhook destinations are validated before delivery, and SSRF checks refuse private and loopback network targets.
Scoped API access
Developer API keys are stored as hashes, scoped to roles, and rate-limited separately from browser traffic.
Environment separation
Test credentials and synthetic providers are locked to loopback and can never run against production data.
Monitoring & abuse detection
Security does not stop at sign-in.
Arrota records and surfaces security-relevant signals so abnormal or blocked behaviour can be investigated by an operator.
Rate-limit exhaustion on authentication, upload and public surfaces
Account lockouts from repeated failed sign-ins
Blocked requests, including refused private-network destinations
Policy refusals, such as domain-gate and self-attestation blocks
Audit logs for sensitive and lifecycle actions
Error and queue monitoring for reliability failures
Background operations
Sensitive work does not disappear into a queue.
Asynchronous jobs are signed, retried and ledgered, so a failure is visible instead of silent.
Signed delivery
Job deliveries are signature-verified against the exact request body and URL before any processing runs.
Outbox-first sending
Emails and transactional webhooks are written to an outbox first, so delivery is durable and traceable rather than fire-and-forget.
Failures are recorded and reviewable
Job attempts keep a status and error record, failures surface in an operator console with counts and review paths, and interrupted uploads resume through single-use tokens instead of silent retries.
Verification security
Verification reveals answers, not records.
A formal check returns structured outcomes about the claims that were asked. It does not hand over the underlying documents or the holder’s account.
Authorised
Requests run against an authenticated verifier organisation, and private information moves only with holder authorisation.
Policy-scoped
The issuing organisation’s disclosure rules decide which fields a verification may return.
Field-level
Matching compares the requested fields against the issuer-confirmed record and returns per-field outcomes.
Minimum disclosure
Mismatched values are not silently revealed, documents are not attached to results, and the request and decision history stays auditable.
Auditability
When something happens, there is a trail and a route.
Audit trail
Sensitive actions are attributed to an account and timestamped on the record itself. Holders and verifiers see the same history.
Incident response
Suspected incidents move through detection, triage, containment, remediation and review, with findings feeding back into controls.
Responsible disclosure
Found something that should not be possible? Email security@arrota.com. Please test only against the demonstration credentials.
Where security meets privacy
Security and privacy meet at control.
The same controls that protect records give holders direct authority over their own information.
- Holders manage what is public and what stays private
- Private share links can be revoked at any time
- Data export and account deletion are available on request
- AI processing runs only with applicable holder consent
Security assurance
Evidence before badges.
Arrota will publish formal certifications only when they are genuinely obtained. Today the evidence is engineering work you can inspect in the product and its behaviour.
Automated security testing
An automated suite covers SQL and row-level-security behaviour, upload rejection paths and known remediations, and runs against every change.
Adversarial security review
A documented adversarial security review has been performed against the running product, with findings tracked through remediation.
Production readiness review
Release evidence is compiled before production changes, including the state of scheduled jobs and recovery steps.
Certifications
Formal certifications such as SOC 2 or ISO 27001 are not held today and will be published here only when genuinely obtained.
Are uploaded documents public?
No. Documents are stored in private storage and reached only through short-lived signed links issued to an authorised session.
How does Arrota control access to private records?
Through authenticated sessions, organisation roles, database row-level security and holder authorisation. Possession of a public identifier grants no private access.
Are credentials digitally signed?
Eligible records carry a signature recorded when the issuer creates them. It anchors origin and content at issue time; it does not re-verify the underlying facts on every visit.
How are uploaded files checked for malicious content?
Uploads are quarantined and the actual file bytes are scanned by ClamAV. Only a clean verdict releases a file. An optional VirusTotal lookup of the file’s SHA-256 hash can block known-bad files but can never release one, and document bytes are never sent to VirusTotal.
Does Arrota use customer data to train AI models?
No. Arrota does not train models on your documents. AI processing is consent-gated and purpose-limited; see the Responsible AI page for the boundaries.
What happens when a credential is revoked or corrected?
The current state changes and the history stays attached. Corrected records show the correction. Revoked records leave public verification, while their history remains available in authorised Arrota views.
Can someone verify a public credential without an account?
Yes. Public verification requires no account and returns only approved public information.
How do I report a security issue?
Email security@arrota.com. Reports use a dedicated route separate from sales and product support; please test only against the demonstration credentials.
Where can I review subprocessors?
The Trust Center lists the providers in the current production architecture and what each one handles. The Privacy Notice remains the authoritative description.
What certifications does Arrota currently hold?
None are held today, so none are displayed. Formal certifications will be published on this page and the Trust Center only when genuinely obtained.
Need to review Arrota more closely?
Security, legal and procurement teams can review our Trust Center or contact us directly with questions.