SECURITY_MODEL.md

The real problem

An agent with full access to the same trust boundary as the secrets can often still abuse them, even if the raw values are encrypted at rest.

The product must therefore:

• separate secrets from agents
• reduce exposed action surface
• authenticate callers
• enforce policy
• support approval
• record audit events

Harbor security model

1. Local-first secret custody

Harbor Node stores service credentials locally.

2. No raw secret return path

No SDK or API should return the underlying credential to the agent.

3. Action-based access

Agents request named actions rather than arbitrary outbound requests with hidden secrets.

4. Policy-first control

Harbor Guard can:

• allow
• deny
• require approval
• apply thresholds
• apply allowlists
• apply rate limits later

5. Audit everything important

At minimum:

• who/what requested the action
• when
• on which Harbor Node
• which Harbor Port
• which policy decision
• whether approval was required
• outcome

6. Premium cloud stays additive

Cloud should add:

• fleet management
• node registry
• premium enablement
• sync
• alerts

Cloud should not be required for the core local trust boundary.

Sensitive action classes

Low risk

• read-only metadata queries
• listing connector health
• reading non-sensitive status

Medium risk

• creating drafts
• creating outbound content not yet sent
• updating low-impact records

High risk

• sending messages
• mutating records in production systems
• refund requests
• billing creation
• bulk export
• deletion
• any future value transfer

High-risk actions should be designed with approval support from day one.

Future hardening notes

Later versions may add:

• stronger local caller auth
• device enrollment
• short-lived tokens
• hardware-backed key support
• remote attestation concepts
• destination allowlists
• anomaly signals