Trust
Security measures
Effective · 25 June 2026 · Version 1.0
This page is maintained by The Aris Group to describe the security posture of the staff workspace at tag.royce.ltd. It catalogues the controls that are currently enabled in the application and the standards we align our practices to. It is not an independent audit, a third-party certification, or a warranty. Where this page refers to industry standards, those standards apply to the underlying primitives we rely on (for example, TLS or AES) and not to any wider claim about the service.
A note on "military-grade"
The term military-grade encryption is industry shorthand for the AES-256 cipher, which is approved by the U.S. National Security Agency (NSA) for protecting classified information up to TOP SECRET under CNSSP-15. AES-256 is the cipher used by TLS 1.3 and by the managed Postgres engine that stores workspace data. We use these primitives as configured by our infrastructure providers. We do not claim FIPS 140-2/140-3 validation, DoD ATO, or any defence-sector accreditation for the workspace itself.
Identity & access
Single sign-on via Discord OAuth 2.0
Sign-in is handled exclusively through Discord's OAuth 2.0 authorisation-code flow with PKCE. The workspace stores no passwords. Anonymous sessions and self-service sign-ups are disabled. The OAuth state parameter is bound to a single-use, HttpOnly, SameSite=Lax cookie to defend against CSRF on the callback.
Whitelist enforcement
Even with a valid Discord token, sign-in completes only if the user's Discord ID is present on the staff whitelist. Non-whitelisted accounts are rejected at the callback and no session record is created.
Role-based access control
Permissions are role-based, with the hierarchy Chairman → Deputy Chairman → CEO → COO → Governors → General Secretary → Company Heads → Staff. Roles are stored in a dedicated table separate from the users table to avoid privilege-escalation patterns, and are evaluated server-side on every privileged request.
Least-privilege publishing
Publishing rights for the holding-wide Notice Board are restricted to Chairman, Governors and Company Heads. Subsidiary-scoped publishing is restricted to officers of that subsidiary. All other members have read and interaction (reactions / RSVPs) rights only.
Session management
Sessions are kept in HttpOnly, Secure, SameSite cookies scoped to the Aris domain. Cookies are signed and rotated on sign-in. Sign-out invalidates the cookie immediately. Inactive sessions expire automatically; revocation in Discord ends access on the next session refresh.
Cryptography & transport
Encryption in transit
All traffic to tag.royce.ltd is served exclusively over HTTPS using TLS 1.2 or TLS 1.3 as negotiated by the client. HTTP requests are redirected to HTTPS. TLS termination is performed by our edge hosting provider with certificates issued by a publicly trusted certificate authority and automatically renewed.
Encryption at rest
The managed Postgres database that stores workspace data, and the object storage that holds any uploaded assets, are encrypted at rest by the infrastructure provider using AES-256. Backups inherit the same at-rest encryption.
Cipher suites
TLS connections use forward-secret cipher suites (ECDHE key exchange) preferred by modern browsers and the edge provider. AES-256-GCM is available and is the same family of ciphers used in standards approved by the U.S. NSA's Commercial National Security Algorithm Suite (CNSSP-15) for classified information.
Secret management
Application secrets (Discord client secret, session signing key, database service role) are stored in the platform secret store, injected into the server runtime as environment variables, and never shipped to the browser bundle. Secrets are not committed to the repository.
Data protection
Row-level security
Every public-schema table has PostgreSQL Row-Level Security enabled. Policies are written against the authenticated user's claims and the role table, so a query can only return rows the signed-in member is entitled to see, even if a client attempts to bypass the application layer.
Server-side enforcement
Privileged operations run through TanStack server functions guarded by an authentication middleware that rejects any caller without a verified session. The service-role database key is used only inside server modules and never reaches the browser.
Input validation
Server function inputs are validated with strict schemas (Zod). Database writes use parameterised queries through the official client library; we do not build SQL by string concatenation.
Output minimisation
API responses return only the fields the caller is entitled to see. Avatar URLs are resolved live against Discord's CDN rather than copied into our database, so revocations propagate without us holding stale copies.
Application hardening
Cross-site request forgery
Mutating server functions require an authenticated session cookie and an Authorization header injected by the in-app client. The OAuth callback validates a single-use state cookie. Cookies are SameSite-protected.
Cross-site scripting
The UI is rendered through React, which escapes interpolated values by default. We do not use dangerouslySetInnerHTML for user-supplied content. Document and notice content is treated as plain text or sanitised rich text.
Open redirects
Post-login redirect targets are validated against an allow-list of in-app paths. External URLs supplied to the redirect parameter are rejected.
Dependency hygiene
The project uses a lockfile and pins dependency versions. Build-time and runtime dependencies are reviewed periodically and updated when security advisories are published upstream.
Rate limiting and abuse
The edge layer applies reasonable per-IP request limits to authentication and write endpoints to slow credential-stuffing and scraping. Persistent abuse results in revocation of workspace access under the Terms of Service.
Auditability
Attributed actions
Notices, task transitions, document edits, calendar updates and role grants are timestamped and attributed to the acting member. The Chairman and Governors can review this metadata for governance purposes.
Role-change log
Grants and revocations of Administrator, Moderator and non-power roles by Head Administrators are recorded with the grantor, grantee, role, scope (which subsidiary) and timestamp.
Backups
The managed database is backed up by the infrastructure provider on a rolling schedule. Restore is performed by the Office of the Chairman in coordination with the provider.
Standards we align to
We do not hold independent certifications for this workspace. The following references describe the published standards that guide our design choices for the controls listed above:
- NIST SP 800-63B — federated digital identity (we federate through Discord rather than holding passwords).
- NIST SP 800-53 — access control (AC), audit and accountability (AU), and identification and authentication (IA) control families inform our role and audit model.
- NIST FIPS 197 — the AES specification underlying at-rest encryption used by our infrastructure providers.
- IETF RFC 8446 — TLS 1.3, the transport standard for all traffic to tag.royce.ltd.
- IETF RFC 6749 / RFC 7636 — OAuth 2.0 and PKCE, the authentication standards used for Discord sign-in.
- OWASP ASVS and the OWASP Top 10 — the web-application security checklists we reference when reviewing changes.
Shared responsibility
What the platform provides
Our infrastructure providers operate the physical data centres, the hypervisors, the managed database engine, the edge network and TLS termination, and the secret store. Their security posture is governed by their own certifications and is outside our direct control.
What we operate
We are responsible for the application code, the database schema and row-level security policies, the role hierarchy, the OAuth integration with Discord, secret usage inside our code, and the day-to-day governance of who has access.
What you must do
Protect your Discord account: enable two-factor authentication on Discord, do not share your session cookies, sign out of shared devices, and report a lost or compromised account to the Secretariat as soon as possible. Do not paste workspace content into untrusted tools.
Incident response
Detection
We monitor application logs and the managed database for unusual access patterns. Members are encouraged to report anything that looks wrong — unexpected role grants, missing records, content they did not post — to the Secretariat.
Containment
On confirmation of an incident, the Office of the Chairman may revoke active sessions, rotate the session signing key, rotate the Discord client secret, tighten the whitelist, and take the workspace offline pending review.
Notification
Where personal data is affected, we will notify members through the workspace Notice Board and, where possible, by direct message on Discord, within a reasonable period after confirming the scope of the incident.
Reporting a vulnerability
If you believe you have found a security issue, please contact the Secretariat via the Office of the Chairman inside the workspace before disclosing it elsewhere. Please describe the issue, the steps to reproduce it, and any potential impact. Do not exfiltrate or modify data belonging to other members while investigating. We will acknowledge your report, investigate, and remediate as quickly as we reasonably can, and we will credit you on the Notice Board if you would like to be named.