Quick AnswerWhat does "governed agent operations" mean in practice?
An autonomous agent can propose work. It cannot approve it, hold a credential, or take a consequential external action by itself.
At DaVeenci the planner and its workers run on a host that carries no production secrets. A separate control plane — an approval ledger, a deterministic policy engine, and an action broker — decides what is permitted and performs the narrow operation itself. A person approves an exact, hashed artifact; that approval is single-use, expires, and cannot be replayed.
Status: architecture v9, verified 1 September 2026. Phase 0 (the control plane) is in build. Nothing below is a claim that the controls already exist in production.
The operating model
Every decision that reaches a client, a prospect, a public channel, or a cloud account is owned by a person — in our case, Anton. The orchestrator holds business context, tracks jobs, selects workflows, and proposes actions. Isolated workers compute and draft. The control plane decides what is permitted.
The framing that matters: the orchestrator is treated as an untrusted planner, not a security boundary. Whichever agent runtime sits underneath, the control plane enforces approval, credential isolation, and policy the same way. Deployment pins a reviewed version and dependency lockfile, disables sandboxing bypasses, and the runtime is re-evaluated quarterly by policy. We chose our runtime because it fits a VPS-first, tool-driven, multi-agent workflow — not because we trust it to enforce anything.
Deployment assumption. Two small VPSs, separated from every other DaVeenci product. The control-plane host runs the ledger, policy engine, broker, and audit log — no model, no untrusted content. The worker host runs the planner, the workers, and a browser, with egress limited to the broker and the model gateway. A root compromise of the worker host yields worker data; a root compromise of the control-plane host is a full-system incident, and is treated as one.
Six rules we do not negotiate
The model never grants permission.
Deterministic code and an explicit human decision control every side effect. Model output cannot edit policy.
Approval binds an exact action.
Content, recipients, attachments, account, job ID, and expiry are hashed and single-use. Change one byte and it is a new job needing a new approval.
Credentials never enter prompts.
The broker is designed to expose narrow operations — createDraft, sendApprovedMessage, createApprovedEvent — and to perform them itself. It never returns a secret to a planner or worker.
External content is untrusted data.
Email and web content cannot expand tools, permissions, or workflow scope. It is labeled, read-only, and cannot trigger new tools.
Uncertain state fails closed.
Crashes, quota exhaustion, duplicate callbacks, and missing acknowledgements pause or reconcile jobs. A lost provider response triggers reconciliation, not a blind retry.
Every important action is recoverable.
Audit, backup, restore, kill, rotation, and spend controls exist before autonomous sends — not after.
Two hosts, one trust boundary
The split exists so that credentials and untrusted content never share a machine with a model.
- Control-plane host — credentials live here; runs no model; reads no untrusted contentApproval ledger and audit (Postgres, hash-chained log, off-host copy) · policy engine (versioned rules, signed changes) · action broker and secret store (encrypted at rest, unlocked by hand after a reboot).
- Worker host — computation zone; no production secrets; egress to broker and model gateway onlyPlanner (its memory and skill writes are reviewed) · confidential-context workers (draft, code, validate — no web egress) · a context-free fetcher (reads web, mail, calendar — no client data, no broker) · versioned artifact store.
Protected against
Prompt-injected email or web content · a compromised planner or restricted worker · changed, expired, replayed, or duplicate approvals · lost responses and at-least-once delivery · a leaked bot token without the approver's identity · accidental destructive commands and runaway spend · exfiltration from a confidential-context worker.
Not protected against by this design alone
Root compromise of the control-plane host · the approver approving a malicious or mistaken action that passes the presentation checks · provider account takeover outside the VPS · chat, mail, model-provider, or cloud-provider compromise · platform enforcement or suspension for prohibited automation.
Writing the second list down is the point. A design that claims to protect against everything is describing a wish, not a boundary.
One action from draft to the outside world
A specialist creates a versioned artifact. A lead reviews quality and scope. The orchestrator proposes an immutable job. A person approves or rejects that exact job from the chat interface. The broker independently reloads the approved object from the ledger, re-computes the hash, runs the policy check, consumes the authorization atomically, performs the operation, and records the result.
Reject or edit → new artifact hash → new approval. There is no "approve this conversation" and no reusable approval. Approvals are risk-tiered and presented in plain text that is never truncated, with look-alike-domain flags; a daily cap on the count of approved external actions exists independently of spend.
Retry rules. Authentication, lockout, verification, and policy errors get zero automatic retries. Transient failures get exponential backoff, jitter, idempotency, and a small per-action budget — default maximum two, platform-specific policy may be stricter. A circuit breaker pauses repeated failures and notifies the approver. This reduces lockout risk; it cannot guarantee an account never locks.
Phase 0: the control plane exists before any workflow
These are deployment requirements, not optional enhancements. Each needs implementation evidence, tests, an owner, a runbook, and deployment configuration before the system is called production-ready.
- Approval ledger and adapterCanonical job, artifact hash, recipients, policy version, nonce, expiry, and state. The chat bot validates the approver's user and chat ID server-side and rejects forwarded, edited, expired, duplicate, or replayed input.
- Policy engine and action brokerVersioned deterministic rules map job type, phase, data class, destination, and risk tier to allow, deny, or approval-required. The broker holds credentials as a separate service user in its own network namespace.
- Audit log, backup, restoreAppend-only, hash-chained, redacted, replicated off-host. Encrypted nightly backup, quarterly restore drill; target RPO 24 hours, RTO 4 hours. A snapshot that has never been restored does not count.
- Spend controller and kill switchDaily and monthly limits, auto-top-up disabled unless separately approved. A chat pause plus an out-of-band provider path revokes leases, disables broker writes, terminates workers, and stays paused across restart.
- Egress policy and secret storeConfidential-context workers reach only the broker socket and the model gateway. Broker secrets are encrypted at rest; after a reboot the system stays paused until unlocked by hand.
- Memory and skill governanceAgent-authored skills and long-term memory writes are diffed, provenance-tagged, and approved before use; auto-generation is off in early phases; memory is versioned with rollback.
- Security detection and stagingCanary credentials planted in worker environments alert on any use. A sandbox mailbox, a second bot, and a dry-run broker that records instead of sends host the acceptance suite before real recipients exist.
Phases, and the gate between them
Each phase becomes available only after its exit criteria pass. Later capabilities do not weaken the earlier rules.
Control plane before workflows
Both hosts, spend controller, kill switch, backup and restore, supervisor, observability, security detection, staging — demonstrated, not described.
Research and drafting
Read-only research, structured qualification, proposals, mail drafts, calendar reading. No client-facing or public action is executable by the agent; a person sends and publishes.
Exact-artifact approval and controlled actions
Approved sends and calendar writes become executable only through broker operations tied to a single immutable approval. Opens only when the acceptance evidence is attached to a release record and signed off.
Formal engineering handoff
Authenticated versioned requests, idempotency, scoped project identity, status callbacks, artifact manifests. Engineering stays an external security domain.
Growth and social
Official platform APIs or manual publishing first. Browser automation ships only after written acceptance of account-suspension and terms-of-service risk.
Creative, client success, compliance, full sentinel
Media generation, onboarding workflows, support triage, case-study drafting, compliance research, and the richer cost dashboard. The Phase 0 hard spend cap stays independent.
Gate rule. Phase 2 does not open on a design review or a successful demo. Among the acceptance tests: changing one byte, recipient, account, action, or attachment invalidates approval; a compromised planner and worker cannot read mail, calendar, cloud, or broker credentials; both kill-switch paths stop new work within 30 seconds; a full clean-environment restore completes within the RTO; a planted canary credential raises an alert within five minutes; an approved update whose target changed since approval is refused and re-queued.
What we measure
Service objectives for the minimum viable system are boring on purpose: backup RPO 24 hours, restore RTO 4 hours, kill latency 30 seconds, and zero tolerated for changed-or-replayed approvals, duplicate external sends, and silent stalls.
- Approval rejection rate — review trigger above 25% over 20 jobsDetects low-quality or poorly scoped drafts.
- Post-approval correction — any consequential caseSignals approval presentation or review failure.
- Task success by workflow — review below 80% for a mature flowPrevents strong aggregate numbers from hiding weak agents.
- Cost per accepted artifact — review at 2× monthly baselineConnects model spend to useful output.
- Human review time — review if no improvement after 30 daysShows whether automation reduces or merely shifts work.
- Policy denial rate — review on a sudden 2× increaseFinds prompt drift, misuse, and overly broad workflows.
Status, cost, and what this is not
This is an architecture and release-gate specification at version 9, verified against vendor documentation on 1 September 2026 and reviewed against the 2026 OWASP Top 10 for agentic applications. It is not proof that the controls exist. Phase 0 is in build; nothing autonomous reaches a client until the acceptance evidence is signed.
Running cost for phases 0–1 is planned in the low hundreds of dollars a month — two small VPSs, model capacity, an off-host backup — with local per-job budgets and provider spending caps as the actual control. The planning range is not the control.
The reason to publish this: every build we ship for a client carries the same shape — narrow roles, explicit gates, append-only records, a person accountable for release. Running our own operations under the same rules is the honest way to find out where they bend.
Frequently Asked Questions
Why not rely on the agent framework’s own permission system?
Because the framework is an untrusted planner in this design. Deployment pins a reviewed version and lockfile, disables sandbox bypasses, and re-evaluates the runtime quarterly; the control plane enforces approval, credential isolation, and policy regardless of which runtime sits underneath.
What happens if the chat bot token leaks?
A stolen token impersonates the bot, not the approver. Approvals are validated server-side against the approver’s user and chat ID with callback nonces and replay rejection, so the token alone cannot approve anything. Rotation is a documented runbook.
Does this slow the work down?
Yes, by design. Human review is a throughput bottleneck, and human review time is one of the six measurements — if automation does not reduce it within 30 days, the workflow is reviewed, not the gate.
Can a client get the same thing?
The same shape shows up in every DaVeenci build — specialist roles, explicit human gates, append-only records, and an accountable release. The full two-host control plane is what the Operate and Improve tier grows into for systems that take external actions. Bring the action you do not dare fully automate.