Security whitepaper
Nodra enforces runtime authority at the action boundary. Protected agent requests are authenticated, evaluated against explicit authority and policy, and recorded as security evidence before consequential execution proceeds.
This page describes Nodra's customer-facing security model, trust boundaries and assurance posture. Internal source code, database implementation and security test internals are not published here.
Nodra enforces runtime authority at the action boundary. Protected agent requests are authenticated, evaluated against explicit authority and policy, and recorded as security evidence before consequential execution proceeds.
Nodra is designed for compromised or misbehaving agents, over-broad authority, replay attempts, credential misuse, unsafe delegation, high-impact actions requiring human review, and incident propagation across related agents.
Customer agent runtime → signed Nodra authorization request → identity, authority and policy evaluation → allow, deny or require-approval decision → customer-owned tool executes only when permitted. Runtime credentials remain server-side.
Workspace isolation, explicit authority, one-way credential storage, replay resistance, attributable evidence, selective containment, evidence-gated recovery and authorized safe restart are treated as security invariants and covered by regression testing.
Nodra does not depend on a specific model, orchestration framework or agent vendor. Any server-side runtime capable of HTTPS can use the signed REST boundary; published JavaScript and Python SDKs simplify the same protocol, and MCP runtimes can guard consequential tool calls.
Nodra records causal evidence, determines affected scope, can restrict affected authority and credentials, and blocks safe restart until configured remediation evidence and authorized approval are complete.
Nodra does not claim SOC 2, ISO 27001, independent penetration-test attestation or contractual SLA coverage unless the corresponding external evidence or agreement exists.