How nodge handles identity, secrets, isolation, supply chain, and accountability. For EU residency and data sovereignty, see the sovereignty page.
A platform's threat model is its list of trust boundaries. Each one names what is untrusted and what guards it. nodge enforces six.
Inbound traffic from the public internet is untrusted. TLS terminates at the edge with header validation, abuse-detection rules, and strict security headers before any request reaches an application.
Traffic between platform services is encrypted with TLS, and each service checks the other's certificate. Every call between services carries its own short-lived, signed authorisation for one exact action, so being inside the cluster grants nothing on its own.
The platform controls tenant workloads, not the other way around. Tenant containers have no write access to platform objects. Tenant code cannot inspect other tenants or initiate platform-internal traffic.
Tenant workloads talk to the platform with a project-bound credential. Scope is limited to that project. Credentials are not interchangeable between deploy, agent, and admin contexts.
For customers running their own cluster, the platform holds no credential for it. It sends signed commands for one exact action, which your cluster checks and carries out itself, and it accepts them only from the platform's own addresses. Your cluster has no administrative reach back into the platform.
Every build runs in its own short-lived runner inside the cluster it builds for, and is destroyed afterwards. It pushes only to that cluster's registry, with a short-lived token for that one project. A compromised build cannot push images or trigger deploys in another project or organisation.
The platform is built and operated under a documented information-security management system covering risk assessment, change control, access management, supplier review, incident response, and business continuity.
Our documented security pack and an independent penetration-test report are available on request under NDA for procurement and compliance review. Email info@nodge.ai.
Your identity provider, your policies. nodge never becomes a parallel identity system for your organisation.
OIDC integration per organisation. Azure AD, Okta, Keycloak, or any OIDC-compliant provider. Your 2FA policies, conditional access rules, and offboarding procedures apply unchanged. IdP client secrets stored AES-256-GCM encrypted at rest. If your IdP revokes access, nodge follows.
An organisation must prove ownership of an email domain via DNS TXT record before users from that domain are routed to its IdP. Cross-organisation domain reclaim is blocked at verification time when active subdomains belong to another organisation.
Each member has individual permission flags rather than a role bundle. Permissions are scoped at both project and environment level, so you can grant production access without granting repository access, or vice versa. No more all-or-nothing role packs.
Configure how many approvers must sign off on a production deploy. Each approval requires a fresh authentication against your own IdP, so your MFA policy is enforced at approval time, not just at login. The original deploy initiator is blocked from approving their own request.
Project data is access-gated at the application layer for every query. Platform administrator actions are themselves audited, so even superuser activity leaves a trail. No silent backdoors.
Defence in depth at every layer that touches secrets, with key material held outside the data it protects.
Sensitive data is encrypted at the application layer with AES-256-GCM. The master key is held outside the database, so a database dump alone does not produce plaintext.
Cluster storage is encrypted in addition to application-layer encryption. Sensitive material like runtime variables, registry credentials, LLM keys, and certificates is protected twice over, with key material held separately from the data it protects.
TLS 1.2+ on every public endpoint with automatic certificate provisioning. HSTS preload and strict security headers at the proxy and application layer. A-graded out of the box, not as a configuration step.
Decrypted values exist only in memory at the moment of use. Plaintext secrets are never logged, never written to disk on the platform host, and never shipped to external observability backends.
Runtime secrets are stored encrypted at rest and only decrypted into memory at deploy time. They are mounted into your application container as environment variables and rotated on every deploy. Plaintext is never written to a host disk.
Pipeline secrets and the platform's own deploy token are scoped to your organisation's repositories and never reach your application code at runtime. TLS material follows the same path. Encrypted at rest, mounted at deploy, never persisted to host disk.
Platform-managed variables sit in a reserved naming scope that user-supplied variables cannot impersonate, so a malicious or accidental name collision cannot escalate a runtime variable into a platform credential.
User sets a secret
-> Encrypted at rest
Deploy runs
-> Decrypted in platform memory
-> Mounted into your container
-> Rotated next deploy
Plaintext on host disk
-> Never.One organisation cannot read another. One project cannot read another. Enforced at the network, storage, and identity layers.
Every project environment runs in its own container with its own network, its own variables, and its own filesystem. Cross-project traffic is denied by default and only opened when you explicitly connect projects.
Even when multiple organisations share infrastructure, network traffic between them is separated at the underlying network layer in addition to access policies. One organisation cannot see another's traffic, even if both share a node.
One organisation's dashboards, logs, and metrics cannot reach into another's. Tenant boundaries are enforced at the observability layer, not just inside the UI.
Each build gets its own isolated runner that exists only for that build. CI from one organisation cannot read another's source code, build artifacts, or pipeline secrets. The container registry is internal to your cluster.
Platform session cookies and tokens are never readable by code you deploy on nodge. Cross-subdomain authentication uses an isolated token-exchange so customer applications cannot impersonate the platform. An attack class that is easy to miss and we close by default.
Every internal service runs with default-deny network policies plus explicit-allow rules for the small set of peers it genuinely needs. Outbound traffic is restricted; inbound traffic is restricted; nothing is open unless we explicitly opened it.
Defence at the edge, in the cluster, and on the host.
A live threat-detection engine watches platform logs and host events for brute-force, scanning, and abuse patterns. Decisions are enforced at the host firewall in real time. Active decisions are reviewable from the admin UI for live triage.
The host firewall is part of the install process, not a manual step left to the operator. IPv4 and IPv6 are configured to the same posture, closing the common gap where IPv6 traffic bypasses an operator-tuned IPv4 firewall.
Dashboards sit behind sign-in, and internal service routes are never published at the edge. No internal surface is reachable without a valid platform session, even if you know the URL.
All state-changing requests are origin-validated. Redirects go through an allowlist. Untrusted input is never inserted into pages, URLs, or commands without validation. Reserved subdomain names are blocked from being claimed by user projects.
Every material action recorded, queryable by scope, actor, target, and time range. Retention configurable per deployment.
Logins, logouts, session revocations, token issue and revoke, failed authentication, and OIDC outcomes with reason on failure.
Identity-provider configuration changes, domain claim and verification, organisation-to-IdP attachment changes.
Manual deploys, signoff request lifecycle, individual approval outcomes with the assurance level the IdP returned, build pin and unpin, pipeline dispatches.
Project and environment creation and deletion, domain changes, member additions, removals, and permission changes across both project and organisation scope.
Approval and rejection of cross-project subscriptions, grant rotation, review outcomes, and agent rollout activity.
Subscription lifecycle, payment outcomes, user lifecycle, admin and organisation-admin role changes, and automatic clean-up of empty organisations.
Manual security-policy decisions from the admin UI, failed authentication patterns, and active threat-detection rulings. Surfaced in the admin UI for live triage in addition to the audit log.
Cryptographic deploy attestation. Two-person deploy approvals are not stored in the rolling audit log. Each approval is a verified identity-provider attestation, signed by your IdP and not by nodge, bound to the specific build under review. It records who approved, when, and at what assurance level. Because it is the cryptographic proof that a specific person signed off a specific release, it is retained for the lifetime of the project and removed only when the project is deleted. Most platforms cannot produce this evidence even on request; on nodge it is a built-in artefact.
Every LLM call goes through the platform's proxy, enforced at the platform layer, not the application layer. Agents never see real API keys.
Agents discover each other through the nodge Center but connecting requires explicit approval. Who publishes what, who subscribes, who approved it. Full audit trail. An agent works with the rights of the person behind it and never more. Every action is available to agents, destructive ones included, and each one can be switched off per project.
Agent identity and deploy identity are cryptographically distinct credentials. An agent cannot trigger a deploy. Each capability gets the minimum credential it needs and nothing more.
Agent requests LLM call
-> Platform proxy handles it
-> Agent never sees the raw key
-> Forwarded to your provider
Agent discovers another topic
-> Requests subscription
-> Admin approves or denies
-> Audit trail: who, when, why
Agent deletes an environment?
-> Only with the person's own rights
-> Only if the project allows it
-> Recorded in the audit trailMost platforms ship containers built by who-knows-what. Every nodge platform image is signed, attested, scanned, and pinned through the same hardened recipe.
Every platform image is cryptographically signed and ships with a software bill of materials and SLSA-conformant build provenance. The signatures and attestations travel with the image so any environment can verify "this image was built by nodge, from this commit, with these dependencies".
Every image is scanned for known vulnerabilities before it can be released. Critical findings fail the build. Application dependencies are audited continuously, including on a daily schedule, with critical and high advisories blocking the merge.
Every code change is analysed for common vulnerability patterns and accidentally committed credentials before it can land. Findings block the merge until fixed or formally reviewed.
Dependencies are checked against a licence policy on every build. Licences that would force unintended source-disclosure obligations are rejected automatically. You will not find a surprise copyleft dependency buried in our supply chain.
Build steps reference exact versions, not floating tags. This blocks the class of attack where a malicious actor pushes a tampered version to a legitimate tool. Every service ships a locked dependency manifest, and a missing lockfile fails the build.
Platform containers run with privilege escalation disabled, all Linux capabilities dropped, and a read-only root filesystem. Anything that needs to write goes through an explicit, audited path. Containers run as a non-root user wherever the upstream image allows.
Platform databases and Git repositories are backed up every night, to backup storage kept apart from the systems they protect.
Per-project backups cover your apps' databases and volumes: every night, before a deploy if you choose, or on demand. The backup service never holds your database passwords or access to your cluster; a short job inside your app's own namespace streams each backup over a one-time link.
Every restore checks each object against its recorded fingerprint before anything is written back, so a damaged or altered backup is refused instead of restored. Backups that are never restored are not backups.
Platform
-> databases and Git, every night
-> stored apart from the live systems
Your cluster
-> nightly, before a deploy, or on demand
-> download or restore it yourself
Restore
-> every object checked first
-> only then written backA breach is a question of when, not if. What matters is how fast you know, how clearly you communicate, and how cleanly you recover.
A documented runbook with notification templates and escalation paths written down before they are needed. As processor we do not notify the authority ourselves; we inform you within 48 hours of discovery so you, as controller, can meet your own GDPR Article 33 deadline of 72 hours.
We are your point of contact for the incident, including a breach at a sub-processor. We give you the information you need for any notification to the authority or to affected people, and keep you updated on progress and on the measures we take as the situation develops.
Most of security is about what you choose not to build.
Each project environment runs in its own container with its own network and its own variables. One app cannot read another app's memory, environment variables, or filesystem.
The proxy holds them. Agents never see them. LLM calls go direct from your deployment to your chosen provider, not through us.
The reverse proxy exposes only what you deploy. No debug ports, no admin panels on public IPs, no convenience backdoors.
nodge does not sit behind an Authentik, Keycloak, or similar third-party identity broker. Auth is handled directly by the platform against your IdP. One less component to patch, one less vendor in the supply chain.
For what nodge refuses to collect, send, or depend on, see the sovereignty page.
Procurement officers and auditors arrive with a checklist. Here is how nodge's controls line up.
| Requirement | How nodge addresses it |
|---|---|
| GDPR Article 32 Security of processing |
Encryption at rest, TLS in transit, access control, full audit log. |
| GDPR Article 33 Breach notification |
Customers notified within 48 hours of discovery, so the controller can meet its own 72-hour deadline. Built into the incident-response runbook. |
| Access, cryptography, communications Technical controls |
OIDC against your IdP, AES-256-GCM with documented rotation, default-deny network policies, TLS at every boundary. |
| NIS2 Essential services obligations |
EU hosting, no American cloud dependencies in the runtime path, full audit log, documented incident response. |
| Schrems II Data sovereignty |
Control plane operated in the Netherlands; you choose your cluster location (default Netherlands), on-premise and air-gapped options, no US-controlled dependencies in the runtime path. |
| OWASP Kubernetes Top 10 Cluster-level threats |
Default-deny network policies, least-privilege service accounts, per-project isolation, secrets encryption at the application and cluster layer. |
Suspected vulnerability? Email security@nodge.ai. We acknowledge within one business day and keep you informed through resolution.
For procurement, compliance reviews, and vendor questionnaires, we share a documented security pack including:
Email info@nodge.ai to start the review.
Cloud, on-premise, or fully air-gapped. The same controls, the same auditability, the same isolation.