Skip to main content

Threat model

This page summarizes enforced controls and residual risk. It is not a certification or a claim that every attack is prevented.

Enforced boundaries​

Cross-tenant access​

Human calls verify ownership or a named team role. Agent calls derive identity from verified Firebase claims, not request bodies. Firestore rules deny direct access to secret-bearing and cross-boundary records.

Stolen or stale agent credentials​

Device keys, scoped keys, and delegations are checked against server state. Revocation increments the session epoch where needed. Delegations expire. Protected actions also require a current, unexpired, unrevoked mandate; suspended agents and stale sessions fail closed.

Approval forgery and replay​

Approval documents are server-written. Decisions are transactional, pending-only, expiry-aware, and bound to an action digest. A denied or expired approval cannot authorize dispatch.

Prompt injection and exfiltration​

Inbound mail receives a prompt-injection risk score. Session tags carry untrusted/sensitive context into policy checks. Recipient/contact and tool-destination checks reduce exfiltration, but scoring is a signal—not perfect prevention.

Tool credential theft​

Tool and connection credentials are encrypted, injected only on the server, and bound to the registered destination. Responses are checked so the injected bearer cannot be echoed back to the agent. Publisher signatures are verified when supplied; unsigned manifests remain accepted for compatibility and should be treated as lower trust.

Mail/webhook forgery​

Ruzayo ingest, bounce, and signed webhook paths verify HMACs. Ingest includes timestamp/replay protection and validates headers to prevent CRLF injection.

Audit rewriting​

The audit ledger is hash-chained and client-immutable. Hourly verification and roots make edits detectable. Payload erasure preserves hash/link fields and is itself admin-audited.

Residual risk​

Compromised project administrator​

A sufficiently privileged Firebase/Google Cloud administrator can read or rewrite Firestore and change functions. Anchors currently live in the same operator boundary, so Ujex does not claim tamper-proof evidence against itself. Independent trust requires customers or another operator to retain published roots and signing keys.

Malicious action inside valid scope​

Ujex narrows authority, budget, destination, and approval conditions. It cannot guarantee that a permitted action is wise. A compromised agent may still harm its own resources within granted scope.

Availability and denial of service​

Cloud platform controls and selected application rate limits reduce abuse, but rate limiting is not yet universal per public endpoint. Shared provider or regional outages can make decisions temporarily unavailable. Clients must fail closed and use bounded retries.

Compromised human browser session​

App Check reduces automated abuse; it does not make a stolen, authenticated browser session safe. High-impact owner actions use explicit holds and remain audit-visible.

Model/provider supply chain​

Ujex does not prove model output integrity or inspect every provider response. Tool allowlists, destination binding, approvals, and evidence provide containment and review—not model security.

Security assurance maturity​

The internal threat model, hardening plan, dependency checks, and test suites exist. A formal external penetration test has not been completed. Ujex does not claim SOC 2 certification.

Operating rules​

  • Rotate credentials and increment session state after suspected compromise.
  • Preserve the project and audit roots before incident cleanup.
  • Do not bypass a failed authorization/risk decision.
  • Treat unsigned tool manifests as compatibility mode, not verified publisher identity.
  • Pin public roots and keys outside Ujex when independent evidence is required.