Threat Model
Every enterprise security review asks two questions: what does this system protect against, and what does it not protect against? This document answers both.
The right answer is not "everything." It is a clear scope of responsibility. The answer below is what an honest security review produces.
The detailed threat catalog with specific deny codes, event signatures, and defense mechanism internals is available to registered customers under NDA.
Trust boundary
PhronEdge enforces at the agent boundary. Your agent code and your business logic run on your side of the boundary. Tool calls cross into PhronEdge for evaluation, then return.
| Domain | Who owns it |
|---|---|
| Agent code and orchestration | You |
| Tool implementations | You |
| Agent infrastructure, runtime, network | You |
| PhronEdge gateway | You (self-hosted) or PhronEdge (SaaS) |
| Signing keys | Your KMS (self-hosted) or PhronEdge (SaaS) |
| Audit chain storage | Your database (self-hosted) or PhronEdge (SaaS) |
In self-hosted deployments, nothing crosses out of your perimeter. This is the core property enterprise security teams verify first.
What PhronEdge protects against
PhronEdge addresses a specific set of threats at the AI agent layer.
Unauthorized agent activity
- Tools not in the signed policy
- Actions beyond the agent's permissions
- Operations in unauthorized jurisdictions
- Delegation outside the approved scope
- Model substitution outside the permitted list
Integrity attacks
- Credential tampering (detected cryptographically)
- Policy tampering (detected by hash comparison)
- Audit log tampering (detected by chain verification)
- Vault-level data tampering (detected by hash re-verification)
Runtime threats
- Prompt injection patterns in agent input
- Behavioral anomalies relative to signed baseline
- Token budget exhaustion and denial-of-wallet
- Replay of expired or revoked credentials
Governance threats
- Shadow AI deployment (ungoverned tools detected by code scan)
- Unreviewed policy changes (signed policy is immutable)
- Silent permission drift (every change is re-signed and event-logged)
Every defense produces cryptographic evidence you can hand to an auditor. The specific checkpoint, deny condition, and regulation citation for each threat is recorded in the audit chain.
Full threat-to-defense mapping with specific detection mechanisms is available to registered customers.
What PhronEdge does NOT protect against
This section matters. A governance layer that claims to protect against everything is untrustworthy.
Compromise of your agent code itself. Within the scope the signed policy permits, the agent can make any decision. PhronEdge enforces the envelope; it does not audit decisions within the envelope.
Vulnerabilities in your tool implementations. If your claim_lookup tool has a SQL injection flaw, that is application-layer security. PhronEdge blocks input patterns you configure as deny_patterns. It does not parse your SQL or audit your code.
Compromise of your KMS. If an attacker obtains your signing key from your KMS, they can produce valid signatures. Detection of this happens through your KMS audit logs. Your responsibility: rotate keys, restrict KMS access, monitor Sign call volume.
LLM provider side-channels. If your model provider is compromised, content between your agent and the model is outside PhronEdge's trust boundary. Use your provider's TLS, authentication, and private networking controls.
Infrastructure-level attacks. Attacks on your Kubernetes cluster, database, or container runtime can compromise PhronEdge itself. Standard infrastructure security applies.
Human error in policy signing. An engineer with signing permissions who signs an overly permissive policy grants too much access. Use the Console's team roles to enforce separation of duties.
Denial-of-service against the gateway. PhronEdge does not include DDoS mitigation. Front your gateway with your standard DDoS-protected load balancer.
Future quantum cryptanalysis. ECDSA P-256 is not quantum-resistant. No cryptographically relevant quantum computer exists today. PhronEdge will migrate to NIST post-quantum signatures when the standards mature.
Defense in depth: the five separated powers
PhronEdge separates governance into five powers. No single component has both decision authority and execution authority. Architectural separation of duties.
| Power | Role |
|---|---|
| Observer | Sees. Cannot act. |
| Judge | Decides. Cannot execute. |
| Enforcer | Acts. Cannot decide on its own. |
| Brain | Coordinates. No access to customer data. |
| Anchor | Records. Cannot modify past events. |
A compromise of any single power does not yield full control. The Observer (read-only) cannot trigger enforcement. The Enforcer (action-only) cannot decide what to enforce. The Brain signs policies but cannot execute them. The Anchor records but cannot alter.
This architecture is why audit events remain trustworthy even under partial compromise scenarios.
The four constitutional laws
PhronEdge enforces four principles that shape every governance decision. They are displayed in the Console.
| Law | Principle |
|---|---|
| Law Zero: Human Sovereignty | Any risk above zero requires human authorization. Overrides all other laws. |
| Law One: Obedience | Follow authorized instructions unless doing so violates Law Zero. |
| Law Two: System Integrity | Protect the governance infrastructure at all times. |
| Law Three: Boundary Awareness | State uncertainty. Never present uncertain outputs as certain. |
These are not marketing copy. Law Zero is what enforces human-in-the-loop at Tier 1. Law Two is what triggers auto-quarantine on tampering. Law Three is enforced at the output constraint checkpoint.
Trust asymmetry
Before you deploy PhronEdge, understand what you are trusting.
You trust PhronEdge to:
- Execute the 7 checkpoints faithfully
- Sign policies with your key only
- Write truthful audit events
- Behave as documented
You do not need to trust PhronEdge to:
- Hold your business data (it never sees it in self-hosted)
- Hold your private keys (they live in your KMS)
- Be online (credentials verify locally)
- Tell the truth about past events (the chain is mathematically tamper-evident)
The second list is the point. Code may have bugs. Cryptographic signatures do not. The chain does the trusting work.
Security posture for your audit
A typical enterprise security review asks these questions. PhronEdge's answers:
Where does our data go? Nowhere. Self-hosted PhronEdge does not transmit business data outside your perimeter.
Who has access to our signing key? No one at PhronEdge. Your KMS, your access controls.
Can PhronEdge modify our audit log? No, the chain is append-only and cryptographically linked. Even PhronEdge cannot modify past events without detection.
If PhronEdge goes offline, what happens? Cached credentials continue governing for the cache TTL. After that, tool calls fail closed.
How do we verify PhronEdge is behaving correctly? Every signature is verifiable with only your public key. Every event is verifiable against the chain. Independent verification requires no trust in PhronEdge.
What happens if PhronEdge is breached? Your signing keys are in your KMS and unaffected. Your audit log is in your database and unaffected. Your business data was never in PhronEdge. The blast radius is your policy definitions, which are backed up in your version control.
Security disclosures
Report security issues to security@phronedge.com. PhronEdge operates a coordinated disclosure program.
Current security posture, penetration test results, SOC 2 report, and detailed vulnerability response procedures are available to registered enterprise customers under NDA.
Next steps
- Signing and verification. The cryptographic basis for every defense
- Compliance matrix. Which regulations each defense satisfies
- Enterprise deployment. How to deploy without extending your trust boundary
- Deployment runbook. Operational security procedures