Technical brief · v0.2
Sovereign Agent Security Baseline
A technical brief on how the Sovereign Agentic Employee deployment is hardened end-to-end. Authored by Travis Piepho (Prospectr Digital) with our deployment engineering partner. v0.2 published 2026-05-27 with the Sovereign Agent rebrand and multi-cloud (AWS, GCP, Azure) updates. Increments to v1.0 after the founding cohort completes.
- Version
- 0.2
- Published
- May 27, 2026
- Audience
- Operators
- Status
- Draft, watermarked
In plain English
In plain English
Your data stays in your cloud account. We never see it. We never store it. We don't have a database with your customers in it because we don't host you. If you fire us tomorrow, your agent, your data, and your infrastructure are all still yours. The technical baseline is below.
1. Threat model
Operators evaluating an agentic employee deployment usually start with a real objection: "I don't want my customer data, financial records, or operational keys sitting on a vendor's servers, governed by their pricing and their availability decisions."
That objection is correct. The Sovereign Agent answers it by deploying into the operator's own cloud account. There is no Sovereign-hosted runtime that holds the keys to your business. The provider relationship is bounded: we deploy and teach, you operate. Pulling our access does not break your Sovereign Agent.
The remaining threat surface is internal - over-broad IAM, mis-scoped skills, leaked secrets, audit gaps, and unmaintained dependencies. The baseline below addresses each.
Four layers is the operator mental model. Five is the runtime containment. Eight is what we deploy and harden during the working session.
2. The four-layer architecture
The Sovereign Agent decomposes into four layers, each with its own security posture. Layer 1 is the orchestrator that receives operator instructions over Telegram and routes work. Layer 2 is the set of skill silos. Layer 3 is durable state. Layer 4 is the guardrail surface - approval gates, audit logs, and the recovery procedures that keep autonomy safe.
Telegram or Slack. Customer chooses at deploy.
2.5 Five layers of containment
The four-layer architecture above is the operator's mental model. Underneath it, the runtime defends with five independent containment layers. Each one is enforced by a different mechanism so a failure at one layer does not chain into the next.
- L1 - Identity rules in the agent's prompt. The role's SOUL file declares red lines (no destructive shell, no PII exfiltration, no policy override). Bypassable in theory by a clever prompt; the next four layers exist because we assume L1 can be tricked.
- L2 - Tool allowlist in DynamoDB. Per-position list of tool ids the agent is allowed to call. Injected into context before SOUL is read. The Finance Analyst role literally cannot see the shell tool; the SDE role cannot see the wire-transfer tool.
- L3 - Per-runtime IAM. Each runtime tier (Standard, Restricted, Engineering, Executive) attaches a different IAM role. The Finance role's runtime has no S3 access to Engineering's bucket. Bypassing this is impossible without re-issuing AWS credentials.
- L4 - Compute isolation. Agents run in isolated compute. On AWS Bedrock AgentCore that means Firecracker microVM per session - a hardware boundary, not a process boundary. On Always-On agents that's an ECS Fargate task with its own ENI. Either way, no shared kernel with other agents.
- L5 - Bedrock Guardrails on input and output. Topic denial, PII filtering, and injection patterns get filtered before the model sees a prompt and after it produces a response. This is the content firewall. Standard tier blocks aggressive categories; Executive tier is unrestricted by design.
L1 and L2 are prompt-level (model-compliance dependent). L3, L4, L5 are infrastructure-level - no prompt, no matter how clever, can bypass an IAM policy or escape a Firecracker microVM.
3. Eight-layer baseline
What we deploy and harden during the mastermind, layer by layer.
| Layer | Risk | Mitigation |
|---|---|---|
| Your cloud account boundary | Provider-hosted agents put your data on shared infrastructure and your operations under their availability and pricing decisions. | Sovereign Agent deploys into your cloud account (AWS, GCP, or Azure). Provider keys can be rotated or revoked by you at any time. There is no shared multi-tenant runtime above your cloud account boundary. |
| Identity and access (Layer 1) | Over-broad IAM allows skills to read or modify resources outside their scope. | Each skill silo gets its own IAM role with least-privilege scoping. The orchestrator does not hold long-lived credentials. Our deployment engineering partner deploys the IAM, secrets, and audit baseline during the working session. |
| Secrets management | Secrets in plaintext config, environment variables, or repo files leak via logs, backups, or developer screens. | Secrets live in your cloud secrets manager (AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault), fetched at runtime, never logged. Resource policies pin each secret to specific principals. Rotation is a one-command operation with zero code change. |
| Skill sandboxing (Layer 2) | A misbehaving skill takes destructive action across systems before a human notices. | Skills are isolated processes with explicit input contracts and approval gates on high-stakes actions. Recovery procedures are documented and rehearsed during Day 2 of the mastermind. |
| State and audit (Layer 3) | Agent decisions and outputs are not auditable after the fact, leaving the operator unable to investigate incidents. | State persists to S3 with object lock for tamper resistance. Every skill invocation is logged with input, output, and decision rationale. Logs are queryable and exportable. |
| Approval and human-in-loop (Layer 4) | Autonomous agents make customer-facing or financial decisions without operator review. | Approval gates are configured by the operator per skill. Drafts are produced for review. Sends, posts, and writes that touch customer or financial systems require explicit approval until you change the policy. |
| Inbound interface | A messaging channel that allows arbitrary instructions becomes an attack surface. | Telegram is paired to specific operator user IDs only. Authentication is bound to the device. Unrecognized senders are silently dropped before reaching the orchestrator. |
| Update and patch posture | A "set it and forget it" agent rots into a vulnerability over months. | The implementation retainer pattern (10 hours per month) covers regular Sovereign Agent core updates, dependency patches, and skill regression testing. Operators on the retainer are not running unmaintained infrastructure. |
| Privileged identity management | Long-lived admin credentials and shared root access create a standing attack surface. A single compromised credential grants full environment control. | Break-glass elevation is role-based and time-bounded. Every privileged action assumes a scoped IAM role with a required external ID, logs to CloudTrail, and alerts the operator in real time. Standing admin access is removed after deployment. There are no shared passwords and no persistent root sessions. |
| Multi-factor access and location controls | Single-factor authentication and unrestricted network access allow credential replay from any location. | Operator console access requires device-bound MFA. SSH is restricted to Tailscale CGNAT range (100.64.0.0/10) - not reachable from the open internet. Telegram channel binding ties the agent to specific operator user IDs. Unrecognized devices and senders are dropped before reaching the orchestrator. |
| Service principals and IAM isolation | Agents that run under a single shared identity can pivot across systems. A compromised orchestrator reaches everything. | Each skill silo and each agent tier runs under its own IAM service principal with scoped resource policies. The orchestrator holds no long-lived credentials - it assumes task roles at runtime with session-scoped tokens. Cross-skill access requires explicit IAM grants, not ambient credential inheritance. |
| Biometric access policy | Biometric authentication introduces hardware dependencies, liveness-attack risk, and legal exposure in regulated environments. | Biometric access is not used in the standard Sovereign Agent deployment. Device-bound MFA and Tailscale network binding provide the access control baseline. Biometric factors may be layered in only when safety engineers are deployed for a specific, documented sovereign agent use case. |
| Responsible AI and model governance | Uncontrolled model access, prompt injection, and autonomous action without human review create legal, reputational, and operational risk. | Sovereign Agent enforces Responsible AI at the architecture level: structured markdown prompt contracts define permitted actions per skill; all external-facing outputs are held as drafts until the operator approves; the model routing layer routes sensitive reasoning (accounting, legal, client-facing copy) to the highest-capability model and lightweight tasks to cost-efficient tiers; audit logs capture every model invocation with input, output, and routing decision. |
Sovereign Agent security baseline - fourteen layers.
Provider-hosted agents put your data on shared infrastructure and your operations under their availability and pricing decisions.
Sovereign Agent deploys into your cloud account (AWS, GCP, or Azure). Provider keys can be rotated or revoked by you at any time. There is no shared multi-tenant runtime above your cloud account boundary.
Over-broad IAM allows skills to read or modify resources outside their scope.
Each skill silo gets its own IAM role with least-privilege scoping. The orchestrator does not hold long-lived credentials. Our deployment engineering partner deploys the IAM, secrets, and audit baseline during the working session.
Secrets in plaintext config, environment variables, or repo files leak via logs, backups, or developer screens.
Secrets live in your cloud secrets manager (AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault), fetched at runtime, never logged. Resource policies pin each secret to specific principals. Rotation is a one-command operation with zero code change.
A misbehaving skill takes destructive action across systems before a human notices.
Skills are isolated processes with explicit input contracts and approval gates on high-stakes actions. Recovery procedures are documented and rehearsed during Day 2 of the mastermind.
Agent decisions and outputs are not auditable after the fact, leaving the operator unable to investigate incidents.
State persists to S3 with object lock for tamper resistance. Every skill invocation is logged with input, output, and decision rationale. Logs are queryable and exportable.
Autonomous agents make customer-facing or financial decisions without operator review.
Approval gates are configured by the operator per skill. Drafts are produced for review. Sends, posts, and writes that touch customer or financial systems require explicit approval until you change the policy.
A messaging channel that allows arbitrary instructions becomes an attack surface.
Telegram is paired to specific operator user IDs only. Authentication is bound to the device. Unrecognized senders are silently dropped before reaching the orchestrator.
A "set it and forget it" agent rots into a vulnerability over months.
The implementation retainer pattern (10 hours per month) covers regular Sovereign Agent core updates, dependency patches, and skill regression testing. Operators on the retainer are not running unmaintained infrastructure.
Long-lived admin credentials and shared root access create a standing attack surface. A single compromised credential grants full environment control.
Break-glass elevation is role-based and time-bounded. Every privileged action assumes a scoped IAM role with a required external ID, logs to CloudTrail, and alerts the operator in real time. Standing admin access is removed after deployment. There are no shared passwords and no persistent root sessions.
Single-factor authentication and unrestricted network access allow credential replay from any location.
Operator console access requires device-bound MFA. SSH is restricted to Tailscale CGNAT range (100.64.0.0/10) - not reachable from the open internet. Telegram channel binding ties the agent to specific operator user IDs. Unrecognized devices and senders are dropped before reaching the orchestrator.
Agents that run under a single shared identity can pivot across systems. A compromised orchestrator reaches everything.
Each skill silo and each agent tier runs under its own IAM service principal with scoped resource policies. The orchestrator holds no long-lived credentials - it assumes task roles at runtime with session-scoped tokens. Cross-skill access requires explicit IAM grants, not ambient credential inheritance.
Biometric authentication introduces hardware dependencies, liveness-attack risk, and legal exposure in regulated environments.
Biometric access is not used in the standard Sovereign Agent deployment. Device-bound MFA and Tailscale network binding provide the access control baseline. Biometric factors may be layered in only when safety engineers are deployed for a specific, documented sovereign agent use case.
Uncontrolled model access, prompt injection, and autonomous action without human review create legal, reputational, and operational risk.
Sovereign Agent enforces Responsible AI at the architecture level: structured markdown prompt contracts define permitted actions per skill; all external-facing outputs are held as drafts until the operator approves; the model routing layer routes sensitive reasoning (accounting, legal, client-facing copy) to the highest-capability model and lightweight tasks to cost-efficient tiers; audit logs capture every model invocation with input, output, and routing decision.
3.5 IM channel security
Sovereign deployments support Telegram and Slack as the operator-facing IM channel. Customer chooses at deploy. Both channels are wired through the same orchestrator and the same audit trail; the security posture is documented per channel below.
Telegram
Bot token stored in your cloud secrets manager. No Telegram cloud retention of agent context - message content lives in your DynamoDB audit table, not Telegram's servers. End-to-end encryption available via Telegram secret chats for high-sensitivity deployments.
Slack
Slack Enterprise Grid supported for retention, eDiscovery, and DLP integration with your existing compliance stack. Bot token stored in your Cloud secrets manager. Audit events double-logged to your audit table and your Slack workspace's audit log API.
4. What we explicitly do not do
- · We do not host your Sovereign Agent. There is no Sovereign multi-tenant runtime above your cloud account.
- · We do not aggregate operator data across customers. Each Sovereign Agent reads and writes only its own account state.
- · We do not retain long-lived credentials in our environment after the working session ends. Credentials are rotated and scope is tightened before you leave Grand Haven.
- · We do not ship skills that take customer-facing or financial action without an approval gate you control.
5. From v0.2 to v1.0
This baseline is published at v0.2 (May 27, 2026) - accurate as of the founding cohort, and the contract we hold ourselves to during the working session. It increments to v1.0 after the founding cohort completes, with cohort-validated changes, explicit cloud service-level coverage, and a documented incident response runbook.
Each increment is announced on this page with a changelog. Operators on the implementation retainer are notified before any breaking change to the security posture lands in their environment.
Have a security question we did not address?
Email travis@prospectrdigital.com or book a 30-minute discovery call. Our deployment engineering partner joins every discovery call where infrastructure questions are in scope.