Security Model

• Server-side agent resolution. The agent identity is derived from the API key on the server. The client never supplies its own agent ID or organization ID.
• Explicit trust boundaries. Hivenora documents exactly what each trust model provides and where its limits are.
• Deterministic decisions. Policy evaluation is rule-based, not probabilistic. The same input always produces the same decision.
• Fail-closed on errors. Network failures throw — they do not produce a default allow decision.
• Tenant isolation. Every query is scoped by the authenticated agent's organization. No cross-tenant data is accessible.
• Audit integrity. All decisions are recorded. The audit log is append-only.

Understanding the difference between these two deployment modes is critical to making accurate security claims about your system.

SDK Mode (current)

In SDK mode, your application code receives a decision from Hivenora and is responsible for acting on it. The enforcement boundary is your code — not Hivenora.

What this means: If a code path in your application bypasses theevaluate() call and calls the tool directly, that action is not intercepted by Hivenora. SDK mode provides application-level guardrails, not an unbypassable enforcement boundary.

Stronger Enforcement Architecture (planned)

In enforcement mode, Hivenora sits as a proxy or gateway in front of protected tools. The agent has no credentials or network path to the tool directly — all calls pass through Hivenora. This provides a stronger boundary than SDK mode.

Enforcement mode is planned. It is not available in the current private preview.

Every API request is authenticated with an API key passed in theX-Api-Key header. Keys are:

• Scoped per agent. A key grants access only to the agent it was issued for.
• Resolved server-side to an agent and organization. The client never supplies its own agent ID.
• Stored hashed at rest (planned pre-launch — currently stored in plaintext in the MVP database).
• Never logged, never returned in responses after initial creation.
• Shown once at creation. Not retrievable after that point.

Hivenora is a multi-tenant service. Tenant isolation works as follows:

• The client never provides an organization_id. It is derived server-side.
• A compromised API key exposes only that agent's organization — not other tenants.
• All router-level queries include an explicit organization scope condition.
• Row-level security (PostgreSQL RLS) is planned as a defense-in-depth layer for the production deployment.

Approvals are bound to a specific action request ID (UUID). The following properties hold:

• An approval for action request A cannot be used to authorize action request B (replay attack).
• Approvals have a configurable expiry (default: 24 hours).
• The Control Room shows the exact action parameters at approval time so the human reviewer sees what they are approving.

Phase 1 limitation: There is no cryptographic binding between the approval and the execution parameters. The agent could theoretically receive an approval for one scope and execute a different scope. Cryptographic fingerprinting of action parameters is planned for a future enforcement mode (see ADR-003).

What Hivenora receives and stores per evaluation:

• The action string (e.g., crm.delete_contacts)
• The intent string
• The context object (records affected, environment, etc.)
• The evaluation result (decision, blast radius, policy matched)
• Metadata: timestamp, agent ID, request ID

What Hivenora does not receive:

• Prompt content or LLM conversation history
• The actual contents of the records to be affected
• Credentials or sensitive payload data

Data residency, retention periods, and detailed privacy policy will be published before the public launch. If you have specific requirements, contact us before integrating.