Astvyr
SECURITY AND TRUST

Autonomy is granted, never assumed.

Astvyr is built on one rule: repository content is untrusted data, and a model is never the source of authorisation. Every privileged action passes a deterministic policy contour with a recorded reason.

TRUST ZONES

Three zones, deliberately separated.

Code and commands can stay inside the customer boundary while the cloud manages metadata and policy.

User

The developer's device and local workspace. Editing keeps working when the cloud degrades.

Astvyr control plane

Policy, orchestration, metering, evidence and administration.

Customer execution boundary

Sandboxes, runners and Production Twins that run inside the customer's own cloud boundary.

SECURITY OBJECTIVES
  • No cross-tenant access to code, prompts, secrets, artifacts, evidence or metadata.
  • Repository content or a prompt injection must never turn an agent instruction into a privileged action.
  • Limit the blast radius of a compromised user, extension, model provider, runner, integration or employee.
  • Provenance and integrity for desktop builds, extensions, runners, artifacts and evidence.
  • Safe manual control and recovery even when the AI, the model or the control plane fails.
THREAT MODEL

Fourteen threats, each with a mandatory control.

This table is the short version. The full model is reviewed for every new data source, model, tool and integration.

ThreatMandatory control
Prompt injection inside a repositoryContent is treated as untrusted data: instruction hierarchy, policy and tool scopes, egress deny, redaction.
Tool privilege escalationSchema-bound tools, attribute-based access control, just-in-time credentials, deterministic approval, audit.
Secret exfiltrationBrokered secrets, process scoping, log redaction, egress proxy, detection.
Cross-tenant isolation failurePer-tenant keys and partitions, access-aware retrieval, isolation tests, dedicated tiers.
Malicious extension or MCP serverManifest permissions, sandbox, signing, review, allowlists, kill switch.
Supply-chain compromiseSigned builds, SLSA-aligned provenance, SBOM, reproducible checks, protected keys.
Model provider leakageContractual zero-retention routes, policy, minimisation, private model option.
Compromised employeeNo standing access, JIT approval, session recording, customer-visible audit.
Session or account takeoverPasskeys and MFA, device trust, anomaly detection, re-authentication for critical actions.
Sandbox escapeMicroVM or dedicated boundary, patched hosts, runtime detection, no shared secrets.
Replay or confused deputyTimestamp, nonce, idempotency, audience binding, fencing tokens.
Compute abuse, such as miningQuotas, behavioural detection, network and process restrictions, hard budgets.
Forged evidenceIndependent runner evidence, signatures and hashes, verifier separation.
Signing key compromiseHSM, offline roots, threshold approval, rapid revocation and a recovery plan.
CONTROLS

Thirty controls, grouped by what they protect.

Identity, isolation, data, agent behaviour, supply chain and the audit trail.

IDENTITY AND ACCESS

  • Passkeys, MFA and device trust with conditional access
  • Workload identity for services, short-lived and scoped
  • RBAC plus attribute-based access for every resource and action
  • Separation of duties: one identity cannot create, verify and approve a high-risk change
  • Just-in-time privileged access with approval, session recording and post-use review; no standing privileged access, including for staff
  • Secret protection through an external vault or broker with customer-managed keys, never exposed in prompts or logs

ISOLATION

  • Per-tenant keys and partitions with isolation tests, and no shared secrets between tenants or jobs
  • Hardened MicroVM sandboxes for untrusted execution, non-root with quotas
  • Egress denied by default, then proxied through a domain allowlist with DNS and SSRF protection

DATA PROTECTION

  • TLS in transit and strong encryption at rest, with managed rotation
  • Model data control: provider policy, minimisation and explicit retention and training terms
  • Data retention and deletion: policy, legal hold, deletion propagation and a report
  • Privacy controls: data map, minimisation, DPA, sub-processors and data-subject requests
  • DLP hooks that can block a prompt, a tool output or an export

AGENT BEHAVIOUR

  • Repository content treated as untrusted data with an instruction hierarchy and prompt-injection defences
  • Schema-bound tool calls with explicit scopes and policy mediation
  • MCP and external tools: consent, audience binding, no token passthrough and SSRF controls
  • Quotas and hard limits against runaway agents, with misuse detection and abuse simulation

SUPPLY CHAIN

  • Secure SDLC: threat modelling, review, tests and NIST SSDF practices
  • Dependency security: pinning, SCA, approved registries and a remediation SLA
  • Build integrity: isolated builds with signed, SLSA-aligned provenance and an SBOM for every artifact
  • Artifact security: OCI-compatible immutable artifacts, scanned on every build
  • Signed staged desktop updates with keys held in an HSM behind offline roots and threshold approval, plus rollback
  • Extension trust: permission manifest, signing, review and revocation

ACCOUNTABILITY

  • Append-only, tamper-evident audit ledger with signed evidence for every release decision, customer-visible export and SIEM integration
  • Monitoring for access, exfiltration, runner, marketplace and abuse signals
  • Vulnerability management: inventory, severity SLA, coordinated disclosure and a bug bounty
  • Incident response: roles, severity, containment, notification and review, with an emergency mode that disables autonomous writes globally while keeping read-only control
  • Backup and recovery: encrypted backups and verified restore
  • Security assurance through independent penetration tests and red teaming, with tracked remediation
RESPONSIBLE AI

Six controls over how an agent is allowed to decide.

Intended use, oversight, fairness, misuse, model change and employee privacy are reviewed as the platform changes.

Intended and prohibited use

Documented intended use, prohibited use and autonomy levels for each agent profile.

Human oversight

Human oversight for high-impact changes, with explicit residual risk and uncertainty.

Bias and fairness

Bias and fairness evaluation where agents influence decisions about people or process, not only code.

Misuse monitoring and appeal

Monitoring for misuse and harmful capability, with a customer appeal and incident route.

Model and provider change management

Change management and communication for material behaviour changes in a model or a provider.

Employee privacy

Team analytics focus on system and outcome, not hidden surveillance or simplistic individual ranking.

MCP AND TOOL SECURITY

An external tool earns its access, every time.

Seven requirements cover MCP servers and external tools from consent through token handling to request forgery.

Current specification baseline

Follow the current MCP specification and its security best practices.

Explicit consent

A server or external tool is connected only with explicit consent.

Scope minimisation

Request the narrowest scopes a tool needs rather than a broad default.

Audience validation

Validate the audience of a token so it cannot be used against another service.

No token passthrough

A tool does not forward a received token to another service.

SSRF protection

Destination and egress checks protect against server-side request forgery.

Explicit tool visibility

Every tool a server exposes is visible, with its permissions, so nothing is invoked unseen.

POLICY CENTER

Policy is data your administrators own.

Eight domains are versioned, simulated before activation and reversible after it.

Models and providers

Allowed models and providers by data classification and region.

Tool and network boundaries

Tool permissions, network destinations, command patterns and filesystem boundaries.

Required checks and approvers

Required checks and approvers by risk class, environment and service tier.

Budgets and limits

Budgets, rate limits, concurrency and maximum Mission duration.

Data lifecycle

Data retention, export, deletion, training opt-in and legal hold.

Allowlists

Extension, MCP server, agent skill and connector allowlists.

Simulation and impact preview

Policy is data with versions and simulation: an administrator sees the impact before activation.

Rollback

A policy version can be rolled back after activation.

IDENTITY

Access follows your directory, not ours.

Provisioning, delegation and removal all originate in the customer identity provider.

  • SCIM provisioning from the customer identity provider.
  • Group sync, so directory membership drives access.
  • Just-in-time provisioning for identities that are not pre-created.
  • Automated deprovisioning when access is removed at the source.
  • Delegated administration: business units manage their own scope under central guardrails.
AUDIT AND REPORTING

One immutable trail, exported where your evidence lives.

Every admin, policy, access, agent, tool, evidence and release event is recorded and readable.

  • An immutable log of admin, policy, access, agent, tool, evidence and release events.
  • Export to a SIEM.
  • Export to a data lake.
  • Export to a GRC system.
  • Export to a customer archive.
  • User-readable session replay.
  • A machine-readable audit API.
  • Evidence packages for internal controls and external audits, without claiming automatic certification.
SUPPLY CHAIN

Every artifact publishes its provenance.

Version, SBOM, provenance, signature and vulnerability response status — for every binary, container and extension.

  • NIST SSDF as the baseline, SLSA-aligned provenance and OCI-compatible artifacts.
  • Every binary, container and extension publishes its version, SBOM, provenance, signature and vulnerability response status.
  • Protected branches, mandatory review, isolated builds, hermetic dependencies, pinned dependencies, approved registries and a licence policy.
  • Separate release signing roles, HSM-backed keys, reproducibility comparison and an independent verification service.
  • Coordinated vulnerability disclosure, security.txt, a bug bounty and published response SLAs.
STANDARDS WE BUILD AGAINST
NIST SSDF SP 800-218NIST AI RMF, Generative AI profileOWASP Top 10 for LLM Applications 2025SLSAOCIOpenTelemetryWCAG 2.2ISO/IEC 27001ISO/IEC 42001SOC 2MCP specification
MARKETPLACE GOVERNANCE

Nothing is installable without a review and a signature.

Trust tiers, permission manifests, scanning, revocation and version blocking govern every published package.

Trust tiers

Public, verified publisher, enterprise-approved and private.

Permission manifest

Shown before install; a change to permissions requires re-consent.

Security review

Automated and manual review for high-risk tools.

Signing

Extensions carry a signature and a malware scan before publication.

Revocation

A kill switch and revocation remove a package from use.

Vulnerable-version blocking

A version with a known vulnerability is blocked from installation.

Commercial terms

Revenue share, usage billing and enterprise procurement support.

SDK

Six layers to extend, each with a stated surface.

From desktop panes to the public event stream, every extension point has a defined contract.

Desktop Extension SDK

Panes, commands, language and Mission interactions.

Agent SDK

Roles, tools, plans, structured outputs, checkpoint and eval hooks.

Connector SDK

Auth, sync, webhooks, actions and customer-side execution.

Policy SDK

Custom rules and decision integrations.

Evidence SDK

Custom checks and artifact viewers.

Public API and event stream

Platform automation.

PRIVACY

Six rules that decide what leaves your boundary.

Data minimisation

Only the fragments and metadata that are necessary reach a provider or analytics.

Purpose limitation

Code and prompts are not used for unrelated training or marketing without opt-in.

Transparency

The interface carries a data map: destination, retention, subprocessors, controls.

User and tenant control

Export, deletion, retention, model and provider choice, residency.

Accuracy and provenance

Citations and freshness, with a route to correct disputed data.

Storage limitation

Default TTL, tiered retention; legal hold is explicit and time-bounded.

RESIDENCY

Where your data lives, and where it does not.

  • The home region holds customer content, embeddings, evidence, primary backups and regional audit.
  • The global directory holds only the minimum routing and entitlement metadata described in the data map.
  • Cross-region support access is off by default, or granted by contract and policy with a JIT audit trail.
  • Model provider calls follow regional and data-class policy: a route cannot silently leave the approved geography.
  • Public marketplace metadata may be global; private packages and usage stay in the tenant's region.
  • Air-gapped delivery arrives with Phase E, alongside sovereign regions operated by a partner or the customer.
DEPLOYMENT OPTIONS
  • SaaSGlobal multi-region service with regional cells.
  • Dedicated cellAn isolated infrastructure cell for tenants and regions.
  • Private cloud / VPCRuns inside the customer's own cloud boundary.
  • Self-hostedCustomer-operated control plane with a higher licence and support floor.
  • Air-gappedFully disconnected delivery for regulated environments.
DATA OWNERSHIP

Every class of data has a named owner.

Ownership is decided per data class, not per feature. Retention, encryption and access follow from that, and customer content is never used for training.

Customer contentCUSTOMERCode, prompts, documents, logs and snapshots. Region-scoped, encrypted, never used for training, with configurable retention.
Operational metadataCONTRACT-DEFINEDIdentifiers, timings, sizes, status and cost. Minimised and retained for service, security and accounting.
EvidenceCUSTOMERTest logs, screenshots and attestations. Policy-defined retention, immutability and export.
AuditCUSTOMER AND PROVIDER OBLIGATIONSAccess, admin, policy and deployment events. Longer retention, tamper-evident, restricted access.
Aggregated analyticsCONTRACT-DEFINEDDe-identified performance and outcome statistics, thresholded so no customer content can be reconstructed.
Marketplace dataPUBLISHER AND PLATFORMPackage metadata, reviews and publisher information under public or private scope, with moderation and retention rules.
COMPLIANCE

A trajectory, with the scope stated honestly.

Certification applies to a specific scope, version and independent audit. Astvyr does not make a customer compliant by itself.

01

Foundation

Governance, control inventory, risk register, asset and data maps, SDLC, vendor management.

02

Trust baseline

SOC 2 Type I readiness or an equivalent independent assessment.

03

Operating maturity

SOC 2 Type II and ISO/IEC 27001 certification as the target.

04

AI governance

An ISO/IEC 42001-aligned AI management system as the target.

05

Regulated expansion

DPA, SCC and transfer mechanisms, residency, customer control mappings.

DRILLS

Practised, not assumed.

A capability that has never failed on purpose has not been tested.

  • Regional failoverAT LEAST TWICE A YEAR ON A MATURE CELL
  • Database restoreMONTHLY SAMPLE, QUARTERLY FULL SCENARIO
  • Signing key compromiseTWICE A YEAR TABLETOP PLUS TECHNICAL EXERCISES
  • Model provider outageQUARTERLY, WITH COST LIMITS
  • Sandbox escapeQUARTERLY SECURITY EXERCISE
  • Marketplace compromiseTWICE A YEAR: REVOKE, NOTIFY, REMEDIATE
  • Major customer incidentTABLETOP WITH SUPPORT, LEGAL AND COMMS
BUSINESS CONTINUITY
  • A critical vendor inventory with exit and failover plans, concentration thresholds and verified contacts.
  • Source, build definitions, signing recovery, infrastructure definitions and runbooks in protected independent locations.
  • An emergency mode that can disable autonomous writes globally while keeping read-only investigation and manual release control.
  • Customer export and self-hosted continuity are considered before any acquisition or termination.
  • Post-incident review measures trust impact and unsafe-action prevention, not only uptime.
VERIFICATION CADENCE

Every security check has a floor, not a best effort.

Appendix D.1 of the platform spec: the minimum frequency for each verification, separate from continuity drills.

  • Critical access reviewQuarterly; high-risk service identities more often
  • External penetration testAt least annually and after material architecture change
  • AI/tool red teamContinuous automated plus quarterly focused exercise
  • Sandbox/runtime reviewContinuous patching, quarterly escape/containment exercise
  • Dependency/container scanEvery build and continuous monitoring
  • Backup restoreMonthly sample, quarterly scenario
  • Incident/tabletopQuarterly; SEV-0 and signing key scenarios at least twice yearly
  • Marketplace package re-scanOn publish/update and continuous intelligence triggers
  • Policy/eval reviewEvery material model/tool/profile release
POLICY

A model never authorises a privileged action.

Authorisation, budgets and forbidden actions are decided outside the model, with a recorded reason and a customer-visible audit trail.