The Sovereign Agent Security Baseline (Companion)

The full security baseline lives at /security. This article is the operator-grade summary - what each of the eight layers means in your business, in plain English, before you decide whether to read the technical brief.

Why eight layers and not three

Most security frameworks for AI deployments stop at “we use IAM” or “we encrypt at rest.” Those are necessary, not sufficient. The Sovereign baseline runs to eight layers because that is the smallest set that lets us answer every reasonable operator question with a specific control instead of a posture.

Here is what each layer does for you, plainly.

1. AWS account boundary

The Sovereign Agent runs in your AWS account. Not ours. This is not a configuration toggle. There is no Sovereign-hosted multi-tenant runtime above your account. You can revoke our access at any time and the deployment continues to operate.

What this prevents: vendor pricing leverage, vendor outage exposure, vendor data-residency uncertainty, and the migration cost most operators discover after they are already locked in.

2. Identity and access (IAM)

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, and tightens scope on every credential before you leave Grand Haven.

What this prevents: a compromised or misbehaving skill from reaching outside its blast radius. The QBO skill cannot trigger marketing actions. The marketing skill cannot read financial records.

3. Secrets

Secrets live in AWS Secrets Manager. They are fetched at runtime, never logged, never written to environment variables that show up in process listings. Resource policies pin each secret to specific principals - the role that needs it, no others.

What this prevents: leaked credentials in logs, repos, backups, screen shares, or developer environments. Also makes rotation a one-command operation when needed.

4. Skill sandboxing

Skills are isolated processes with explicit JSON Schema input contracts. They cannot share memory or tail each other’s logs. If a skill takes destructive action, the blast radius is bounded by its IAM scope and its input contract.

What this prevents: cascade failures where one bad skill takes the whole agent down or, worse, takes a real action across systems before a human notices.

5. State and audit

State persists to S3 with object lock for tamper resistance. Every skill invocation logs its input, output, and decision rationale. Logs are queryable and exportable. When something goes wrong, you can reconstruct what the agent was thinking, not just what it did.

What this prevents: forensic debugging after an incident. Auditability is concrete, not aspirational.

6. Approval and human-in-loop

Approval gates are configured by you per skill. Drafts can flow autonomously. Sends, posts, and writes that touch customers or money require explicit approval until you change the policy. Every approved action is logged with the human reviewer.

What this prevents: autonomous agents making customer-impact decisions without operator review. The default posture is conservative; you loosen it as you build trust in each skill.

7. Inbound interface

Telegram is paired to specific operator user IDs only. Authentication is bound to your device. Unrecognized senders are silently dropped before they reach the orchestrator.

What this prevents: prompt injection from a hostile inbound channel. The Telegram surface only listens to people you have authorized.

8. 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.

What this prevents: running unmaintained agentic infrastructure, which is the most common way agentic deployments fail in year two.

What we explicitly do not do

This is the section operators usually ask for and rarely get from vendors:

• We do not host your Sovereign Agent. There is no Sovereign multi-tenant runtime above your AWS 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. Credentials are rotated and scope tightened before you leave Grand Haven.
• We do not ship skills that take customer-facing or financial action without an approval gate you control.

How to use this

Before a discovery call, read this. If anything in it does not match your security posture, tell us - we either confirm we have a control for it or we tell you up front we do not.

After a discovery call, the full technical brief at /security is the document you forward to your security or compliance reviewer. It includes the threat model, the eight-layer table, and the roadmap from v0.1 to v1.0.

To start the conversation, book a 30-minute discovery call. Our deployment engineering partner joins any call where infrastructure questions are in scope.