---

🔐 Security Whitepaper

Version 1.0 — December 2025

---

📘 Executive Summary

SymphonyDesk is a secure automation orchestration platform built for hybrid and multi-tenant environments. Security is foundational to the product design — not added as an afterthought. This whitepaper describes the platform’s security architecture, authentication model, tenant isolation methods, and operational hardening strategies.

The system is explicitly designed for:

• Enterprise-grade authentication separation
• Zero trust runners
• Multi-tenant isolation
• Least privilege principles
• Auditable, deterministic job execution
• Secure script delivery and update control

SymphonyDesk’s security model ensures that automations triggered by service desks, system operators, or integrated systems cannot access or interfere with other customers or tenants.

---

1. Platform Architecture Overview

SymphonyDesk consists of three independently authenticated subsystems:

1. Control Plane (FastAPI Cloud Backend)
   • Manages job orchestration, runbook manifest distribution, logging, authentication, and tenant isolation.
2. SymphonyRunner (On-Prem or Hybrid Execution Runtime)
   • Polls for jobs
   • Executes PowerShell runbooks
   • Syncs runbooks securely
   • Reports execution outcomes
3. Web Dashboard (Browser-based UI)
   • Used by human operators and admins
   • Displays job history, statistics, runner health, and logs

These subsystems authenticate differently, maintain strict key boundaries, and cannot impersonate each other.

---

2. Authentication & Key Management

SymphonyDesk employs three separate authentication mechanisms, each scoped to its use case.

2.1 Client API Keys (for /run)

Used by external systems such as:

• Service Desk software
• Microsoft 365 automation flows
• ITSM systems
• Internal tools

Properties:

• Unique per customer
• Scopes all automation requests to that customer only
• Expirable and revocable
• Defined in environment variable CLIENT_API_KEYS_JSON

Customer Isolation Enforcement:

Even if a caller specifies another customer in the payload:

/run { "customer": "SomeOtherCustomer" }

It is ignored and overridden to the API key’s tenant.

---

2.2 Runner Authentication Key (for /jobs/*, /runbooks/*, /runners/heartbeat)

Only SymphonyRunner uses this key.

Properties:

• Long-lived but rotateable
• Has access ONLY to runner-specific endpoints
• Cannot trigger jobs
• Cannot interact with UI
• Cannot impersonate clients

This prevents compromised runners from triggering arbitrary automations.

---

2.3 JWT Authentication for UI Users

Web dashboard users authenticate with:

• Email + Password
• JWT Access Tokens

Properties:

• Token contains customer claim
• Enforces tenant isolation
• Revocation supported via user deletion/reset
• No cross-customer visibility

---

3. Tenant Isolation Model

SymphonyDesk is designed from the ground up for multi-tenant safety.

3.1 Isolation Mechanisms

• Each customer’s jobs are stored in isolated directories (/jobs/<customer>).
• Runner status files are similarly isolated.
• Client API keys map exactly one customer.
• UI enforces customer identity via JWT token claims.

3.2 Cross-Tenant Protections

• Runners can only execute jobs for the customer they are configured with.
• The /run endpoint rejects mismatched customers.
• UI users cannot view or manipulate other customers’ jobs.
• Runbook sync is scoped to a customer (optional future RBAC per-script).

No customer can generate jobs for another tenant, view another tenant’s logs, or sync their runbooks.

---

4. Data Security & Encryption

4.1 Data in Transit

All endpoints require HTTPS/TLS 1.2+.

• No plaintext API URLs
• Runners communicate exclusively via HTTPS
• Token-bearing endpoints require secure transport
• No sensitive data is ever returned over unencrypted channels

4.2 Data at Rest

By default:

• Job files
• Runbook manifests
• Runner heartbeat state
• JWT secrets

are stored within the secure Azure App Service or container file system.

You may optionally configure storage to:

• Azure Blob Storage
• AWS S3
• Encrypted disk volumes

---

5. Job Execution Safety (SymphonyRunner)

The SymphonyRunner is intentionally zero trust and pull-based, meaning:

• The cloud never initiates a connection into customer networks
• No inbound firewall ports are required
• Runners connect outbound only

5.1 Execution Sandbox Characteristics

Process Isolation

Runbooks are executed via:

pwsh.exe -NoProfile -ExecutionPolicy Bypass -File <script>

• Each job runs in its own PowerShell 7 process
• Standard output and error are captured to temp files
• Execution timeout defaults to 15 minutes
• Runner kills hung processes

Log Size Enforcement

To prevent crashes, API overload, or UI lock-ups:

• Logs > 20,000 characters are truncated
• Large outputs cannot overwhelm the control plane

Runbook Update Security

Runner verifies:

• Version
• Checksum (if provided)
• Manifest authenticity

before downloading new scripts.

Scripts are stored with a corresponding .meta.json:

{
  "name": "ACT-CreateRemoteMailbox",
  "version": 2,
  "checksum": "abc123",
  "updatedAt": "2025-11-30T13:00:00Z"
}

---

6. API-Level Security Controls

Rate Limiting (recommended)

/run can be optionally rate-limited per customer.

Audit Logging

All major operations can be captured:

• Job created
• Job executed
• Script version changes
• Runner heartbeat
• Authentication events

Error Sanitization

Internal traceback details are never exposed.

Input Validation

• Only whitelisted script names are executable
• Parameters are serialized safely
• Dangerous characters can be filtered

---

7. Runbook Security & Supply Chain Considerations

7.1 Script Authenticity

Runbook manifests distributed by the API define:

• Allowed script names
• Version numbers
• Checksums
• Download URLs

The runner refuses:

• Unknown scripts
• Scripts not listed in manifest
• Scripts with mismatched checksum (when used)

7.2 Supply Chain Protection

Recommended production approach:

• Store runbooks in private GitHub repo
• Deliver via signed release assets or protected raw endpoints
• Generate manifest automatically from CI/CD
• Add SHA256 checksum per file

This prevents tampering at rest and in transit.

---

8. Threat Model

SymphonyDesk considers threats across the entire automation lifecycle.

8.1 Threat Scenarios & Mitigations

1. Compromised Client API Key

Mitigation:

• Scopes to one tenant
• Cannot execute admin endpoints
• Cannot access UI
• Rotatable and revocable

---

2. Compromised Runner

Mitigation:

• Runner only executes jobs for its tenant
• Cannot create new jobs
• Cannot see other tenants
• Cannot trigger UI or administrative functions
• Cannot push arbitrary logs or metadata
• Poll-only model; no inbound control

---

3. Cross-Tenant Data Leakage

Mitigation:

• Strict customer scoping in all APIs
• Directory isolation on disk
• JWT customer claims enforced
• Independent API keys per customer

---

4. Malicious Runbook Injection

Mitigation:

• Only scripts listed in manifest are executed
• Optional checksum enforcement
• Controlled, versioned script store

---

5. Script Running Too Long / Hanging

Mitigation:

• Process timeout
• Forced kill
• Sanitized logs
• Truncated output

---

6. Man-in-the-Middle Attack

Mitigation:

• TLS 1.2+ required
• No plaintext endpoints
• API keys never sent insecurely

---

7. Cloud Credential Compromise

Mitigation:

• Separate environment secrets
• Zero capability overlap
• One secret cannot impersonate another subsystem
• Tokens revocable

---

9. Compliance-Ready Design

SymphonyDesk includes features aligned with common compliance frameworks:

• SOC 2 / ISO 27001:
  • Key rotation
  • Audit logs
  • Principles of least privilege
  • Secure software development
• GDPR / Data Sovereignty:
  • Customer-scoped storage
  • No unnecessary PII stored
  • Tenant isolation
• Enterprise Zero Trust:
  • No inbound connections
  • Authentication separation
  • Principle of minimal access

---

🔚 Conclusion

SymphonyDesk is engineered with a strong, layered security posture that safeguards:

• Job integrity
• Script authenticity
• Customer isolation
• Runner safety
• Secure communication
• Operational control

This whitepaper demonstrates that SymphonyDesk is not only a powerful automation platform but one built on secure, principled architecture appropriate for enterprise-scale deployments.

---