Catalog PyPI
PACKAGE EXPLORERView in registry

agentevo-cloud

PyPI

Agentevo SaaS (TZ-3 control plane, TZ-4 managed intelligence): auth, metering, C2 APIs, workers.

agent-memoryai-agentsguardrailsskills
Versions collected1
Direct dependencies8From release 0.2.17
Last observed20 Oct, 21:53 UTC

README

Version 0.2.17 documentation

agentevo-cloud

Agentevo SaaS planes: control API (TZ-3: auth, tenants, metering, sync) and managed intelligence API (TZ-4: tenant-scoped recall, async verify/compile jobs, analytics), plus the agentevo-cloud operator CLI (provision, serve, jobs, webhooks, health, export, backup, privacy).

python3 -m venv .venv  # Python 3.10+
.venv/bin/pip install agentevo-cloud
.venv/bin/agentevo-cloud provision --tenant t-1 --name demo --user u-1 --workspace main
.venv/bin/agentevo-cloud serve

A virtualenv keeps pip off the system Python, which macOS Homebrew and Debian/Ubuntu refuse to modify (PEP 668).

Part of Agentevo.

Encrypted runtime release

Cloud 0.2.9 is the pending source version for authenticated accepted event context, reviewed legacy transitions and the existing encrypted storage, provider and backup controls. Verified 0.2.8 artifacts and consumer seal remain preserved; 0.2.9 is not built/sealed/cold-installed yet. A local passing test alone does not establish publication, deployment or complete operating acceptance.

The optional encrypted extra pins sqlcipher3==0.6.3. For source development, install it with uv sync --frozen --package agentevo-cloud --extra encrypted. After final publication, the package selection is agentevo-cloud[encrypted]==0.2.9; use the approved hashed, wheel-only consumer lock for a hosted image. Installation alone does not activate encryption.

Select AGENTEVO_DB_STORAGE=sqlcipher-v1, an explicit public AGENTEVO_DB_KEY_ID and AGENTEVO_DB_KEY_FILE for every API, worker and operator process using the same database. The key file must contain exactly 32 raw bytes, be owned by that runtime user with mode 0600, and be mounted from independently recoverable protected storage. No default key is supplied. Missing runtime, missing/wrong keys or a plaintext database in the encrypted profile are refused; the profile never falls back to plain SQLite. The default plain profile exists for legacy compatibility and does not encrypt live rows.

Existing plaintext needs a separately verified new-file conversion; selecting the profile does not convert it. Preserve older plaintext recovery points under their reviewed retention policy, and keep the correct old database keys and independent archive/journal authority for encrypted recovery points. Native application and operator paths have local acceptance evidence. Linux image execution and independent operating custody remain separate gates. The source checkout contains the detailed design and conversion procedure in docs/implementation/LIVE_DATABASE_ENCRYPTION.md; public setup is at Agentevo setup.

Private recovery controls

Encrypted online snapshots support verified filesystem publication and recovery into a new private database. Recovery requires independent keys, the authenticated erasure journal, its independently trusted latest head and a current approved retention policy. The selected sqlcipher-v1 profile encrypts live database storage; the legacy plain profile leaves searchable rows readable in copied databases. Archive encryption does not establish live-data encryption or off-host custody. Protected application backups require their own archive key with different material from the online database key. Legacy gzip restore refuses encrypted or privacy-protected databases; use the authenticated operator recovery path with current independently retained authority instead.

Optional AGENTEVO_ERASURE_JOURNAL and AGENTEVO_ERASURE_KEY_FILE configure the same authority for API, workers and operator commands. Protected databases refuse missing authority. Recorded erasures, revocations, consent and retention decisions are reconciled before restored data is used. Permission increases require a postcommit confirmation; uncertain decisions remain unavailable until explicit private operator resolution. privacy authority-status, authority-resolve, authority-reject and reconcile support that procedure without journal editing.

Protected restore requires the source's protection marker and authenticated applied/minimum journal heads to exist already. Historical snapshots from before activation are refused; a new empty journal cannot prove earlier revocations. Review a current baseline before activation and preserve independently current authority. The guard cannot reconstruct unrecorded historical decisions.

privacy retention defaults to a read-only approved-policy preview. Apply needs an explicitly activated matching policy and a fresh matching preview seal. Use agentevo-cloud backup --help and agentevo-cloud privacy --help for exact arguments. Keep previous artifacts, archive keys and journal verification keys for every retained recovery point. Unrecorded decisions before activation need a reviewed transition; real operating recovery remains a separate acceptance gate.

Queued job authorization

Schema 29 records private accepted submitter authority for new asynchronous jobs. Workers recheck credential ancestry, membership and the required workspace and operation grants before claim and result application. Clerk work also checks the accepted public signing key, original expiry, exact current account link and fresh configured provider/session status. Provider outages defer work without applying a private result; withdrawn authority cancels it. Provider reads occur outside database/privacy fences. Session-event compilation needs a tenant-wide grant because its input events have no workspace attribution.

Existing jobs keep an unknown submitter. Workers cancel unbound queued/running work with JOB_AUTHORITY_UNKNOWN and clear its private parameters/results; resubmit needed work through a currently authorized API. The migration never infers an owner or promotes old work to operator authority. Public job responses omit the private binding; account export includes sanitized attribution only. These local controls do not establish real-provider or deployed acceptance.

Accepted event evidence

Schema30 retains bounded, screened canonical source/client time/environment/ provenance for new event ingestion. A protected acceptance capsule binds exact context and payload bytes, tenant/session/sequence/type/classification and server receipt using the active independent journal verification key. Compiler input and result application reverify it; the original core event hash/wire is unchanged. Unconfigured context is explicit unattested evidence. Retain all verification keys needed by surviving events and recovery points.

Ordinary protected upgrade with existing schema29 events refuses. It needs an explicit trusted-library transition bound to an externally reviewed exact missing-row baseline and current independent head; there is no automatic CLI, environment or SQL approval. Historical context staysNULL and its signed marker witnesses only observed absence. Restore never creates that approval and verifies retained capsules before publication. Do not strip evidence or downgrade the schema marker for rollback. The source checkout's docs/implementation/PRIVACY_OPERATORS.md documents the operating gate.

Acceptance is not session closure, causal completeness, permission or event retirement. Finite events/audit/billing/snapshot retention remains refused; new release, real historical baseline/custody and final operating/deployed acceptance remain separate gates.

License

Business Source License 1.1 — see the LICENSE file shipped with this package. Free for internal production use in your own infrastructure; converts to Apache-2.0 on the Change Date stated in the license.

Downloads & popularity

Awaiting observations

No metric observations yet

Download counts and popularity will appear here as the collector receives them.

Versions 1

Collected releases
VersionPublishedDirect dependenciesOpen version
0.2.1720 Oct 20268

Package advisories

0
No matching advisories collected

This describes our collected data; it is not a security assessment.

Metadata history

Meaningful changes
Current collected state Current

Observed since 20 Oct, 21:53 UTC

No superseded metadata states collected. Unchanged observations do not create new revisions.

Record identity

package:20ffbe1dfd148c66666a1397ef110320c0795ba41396c20a4bf1fc94a4277c82