How Nodge handles identity, secrets, isolation, supply chain, and accountability.
Every layer of the platform is open-source software running on European infrastructure. No American-owned dependencies in the runtime path, no phone-home telemetry, no managed control plane reaching in from outside.
Run Nodge in our EU cloud, on your own servers, or fully air-gapped. Self-hosted deployments work entirely offline after install. All organisation data and metadata stay inside the environment you chose.
Built for organisations where data residency, GDPR compliance, NIS2 obligations, and Schrems II rulings are non-negotiable. No exposure to the US CLOUD Act on the platform itself.
Reverse proxy routing, SSL, DNS
Git hosting repos, access control
CI/CD runner build, test, deploy
Image registry container storage
Metrics engine per-project monitoring
Dashboards pre-configured, built-in
Log aggregation query by project, time
Event bus pub/sub, audit trail
LLM proxy budget enforcement
Platform auth, API, controlA 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.
Internal traffic between the edge and backends passes a session-validating gate on every gated route. No internal surface is reachable without a valid platform session, even from inside the cluster.
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 compute, the platform connects via an encrypted credential held outside the customer cluster. The customer cluster grants workload-level access only. Never administrative reach back into the platform.
Per-organisation build runners, per-project deploy credentials. There are no shared CI workers across organisations. A compromised build in one organisation cannot push images or trigger deploys in another.
Our organisation is certified against ISO/IEC 27001:2022 by an RvA-accredited certification body. The information-security management system that produces this platform (covering risk assessment, change control, access management, supplier review, incident response, and business continuity) is audited annually against the standard.
Certificate copy and the statement of applicability are available on request 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. Per-project schema separation in the database too.
Each organisation gets its own isolated build runners. CI from one organisation cannot read another's source code, build artifacts, or pipeline secrets. The container registry is internal to your environment.
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.
The Git UI, monitoring dashboards, and browser IDE all sit behind a session gate at the proxy. 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. Agents never see real API keys. Hard EUR budget caps per project enforced at the platform layer, not the application layer. Track costs in real time, kill a runaway agent with one click.
Agents discover each other through the Nodge Center but connecting requires explicit approval. Who publishes what, who subscribes, who approved it. Full audit trail. Destructive actions are human-only: agents can create, read, and build, but deleting projects or removing members requires a human with the relevant permission.
Agent identity and deploy identity are cryptographically distinct credentials. Your CI pipeline cannot spend an agent's LLM budget. An agent cannot trigger a deploy. Each capability gets the minimum credential it needs and nothing more.
Agent requests LLM call
-> Platform proxy checks budget
-> Budget OK? Forward to provider
-> Log: model, tokens, cost, time
-> Budget exceeded? Blocked.
Agent discovers another topic
-> Requests subscription
-> Admin approves or denies
-> Audit trail: who, when, why
Delete a project?
-> Agent can't. Human only.Most 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, Git repositories, and certificate material are backed up nightly. Per-project backups cover project data and project files. Backups are encrypted before they leave the platform host, using a key the platform itself does not hold.
Off-host copies sit on a separate, dedicated backup target that the platform can write to but cannot read back or delete from. Even an attacker with full platform access cannot tamper with or wipe historical backups. A property most backup systems do not provide by default.
The decryption key lives in a password vault and never sits on the platform. Restore is a deliberate human action that happens outside the platform, so a compromised platform cannot silently restore stale or attacker-chosen data into your environment.
Recovery drills are run quarterly and the date of the last successful drill is on record. Backups that are never restored are not backups.
Platform host
-> nightly bundle assembled
-> encrypted before it leaves
-> pushed to backup target
Backup target
-> write-only for the platform
-> platform cannot read back
-> platform cannot delete
Restore
-> key held in vault, off-host
-> deliberate human action
-> initiated outside platformA 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 a 72-hour notification clock aligned to GDPR Article 33. Customer notification templates, escalation paths, and response-time commitments are written down before they are needed.
Every incident closes with a written post-mortem covering timeline, root cause, mitigations applied, and structural changes to prevent recurrence. We share post-mortems with affected customers, not just internally.
Most of security is about what you choose not to build.
Nothing is sent to us. No analytics, no usage tracking, no "anonymous" metrics. The platform does not phone home.
Some "self-hosted" platforms still reach back to a central control plane. Nodge has zero external dependency after install.
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.
Your prompts, your agent conversations, your code. None of it is used to train anything. It stays on your environment.
The reverse proxy exposes only what you deploy. No debug ports, no admin panels on public IPs, no convenience backdoors.
You control when and if you update. No silent background patches. No surprise changes to your running platform.
No session recordings, no heatmaps, no engagement metrics baked into the platform. We don't watch how you use it.
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.
Most of what a platform can leak is what it chose to collect.
We chose not to.
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 |
72-hour notification clock built into the incident-response runbook. |
| ISO 27001:2022 Information security management |
Organisation certified by an RvA-accredited body. ISMS audited annually. |
| ISO 27001 A.9 / A.10 / A.13 Access, cryptography, communications |
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 |
Hosted exclusively in the Netherlands, on-premise option, 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 security model, the same auditability, the same control.