Current contract or code path
The backend, API, or worker currently implements the behavior described. A deployment still has to run supported code and configuration.
Security without vague promises
Know the boundary. Know who enforces it.
RustGrid centralizes tenant context, authorization, safe mutation contracts, integration trust, and operational history. Agent execution adds another boundary whose strength depends on the worker and host you actually deploy.
No compliance certification, uptime guarantee, or universal deployment assurance is implied on this page.
How to read this page
Controls are labeled by where their truth lives.
Operator-owned enforcement
The control depends on secrets, hosts, network policy, storage, resource limits, GitHub settings, or other deployment choices.
Direction, never evidence
A planned control would be labeled explicitly and must not be treated as available. This page does not rely on planned work as security proof.
Authorization path
Tenant context begins with the credential.
Protected HTTP requests use a tenant-scoped JWT for user traffic or an rgk_ API key for automation. RustGrid derives the active tenant from authentication and rejects X-Tenant-Id rather than trusting it as a caller-selected boundary.
Authenticate
Bearer JWTor rgk_••••
Resolve tenant
credential contextheader rejected
Authorize
RBAC permissionor API key scope
Protect write
If-MatchIdempotency-Key
Record
x-request-idaudit history
Boundary checks5 / 5
Credential accepted
Resource in tenant
Actor policy checked
Version precondition
Trace appended
- Response
- 200 OK
- Credential
- [REDACTED]
- Trace
- x-request-id: req_••••••••
Illustrative request trace. ETags and idempotency apply where the current endpoint contract requires or supports them; the example does not imply every request performs every mutation check.
Implemented controls
Security belongs in the shared workflow core.
Human interfaces, API clients, agents, and integrations meet the same backend boundaries instead of reimplementing them in each frontend.
Tenant context
Protected routes derive tenant scope from the authenticated credential. Caller-supplied tenant headers are rejected.
Implemented
User authorization
Effective tenant and project roles expose explicit permissions for reading, writing, membership, integrations, audit, and administration.
Implemented
Machine authorization
Tenant- or project-scoped rgk_ API keys carry server-side scopes. The plaintext key is returned only at creation and can be revoked.
Safe mutation
Supported writes use idempotency for replay safety and strong ETags with If-Match where optimistic concurrency is required.
Trace and history
Responses include or propagate x-request-id; workflow mutations and integration events feed durable activity or audit history.
GitHub trust
Installation setup binds exact state and installation identity, verifies user access with PKCE, confirms App inventory, and validates webhook signatures.
Implemented
Secret exposure
The GitHub installation flow does not persist user OAuth access or refresh tokens. Service observability redacts bearer secrets from authorization metadata.
Implemented
Plan-aware retention
Audit retention is an explicit plan entitlement. The live billing response is authoritative for the current tenant value.
ImplementedAgent execution boundary
Isolation is real only when the deployment enforces it.
The RustGrid agent supports a per-run production boundary with Docker Sandboxes, but the resulting assurance depends on the host, immutable sandbox template, resource policy, network policy, credentials, storage, and staging evidence.
The current production executor depends on Docker Sandboxes and Docker Desktop; it is not available on Linux hosts. Local execution is not equivalent to the production microVM boundary.
Execution controlsDeployment-dependent
Per-run microVM
Each production run receives a distinct Docker Sandbox and disposable clone.
Host requiredCredential split
Worker credentials stay in the coordinator; run GitHub tokens are held in memory and validated against the manifest.
Worker requiredEnvironment
Child environments are rebuilt from an allowlist; control-plane credentials stay outside the mounted clone.
Policy requiredResources
Worker limits add defense in depth, while continuous CPU, memory, disk, and network enforcement remains a host responsibility.
Operator requiredDeployment responsibilities
The platform cannot replace secure operations.
These are required boundaries around the product, not optional polish and not assurances delivered by a marketing page.
Secrets and identity
Store application keys, OAuth client secrets, webhook secrets, worker credentials, and Codex authentication in an appropriate deployment secret manager. Rotate after suspected exposure.
HTTPS and network policy
Use HTTPS for public callbacks. The current agent requires network access; exact destination restrictions remain an operator or organization-governance responsibility.
Sandbox host
Pin the production template by verified digest, use an unprivileged host identity, reserve capacity, set quotas, and validate escape isolation in credentialed staging.
GitHub configuration
Grant only required App permissions, configure exact callback and webhook URLs, approve permission changes, and verify repository rules separately.
Storage protection
Encrypt and access-control persistent databases, object storage, telemetry, and retained failed workspaces. Configure retention cleanup for proprietary repository data.
Promotion and monitoring
Run migrations, complete credentialed staging against the production topology, monitor workers and webhooks, and retain incident evidence without exposing secrets.
Data handling
Understand what crosses each boundary.
Mission execution can involve requirements, comments, attachments, repository source, command output, branch names, pull request URLs, and operational identifiers. Treat all of it as potentially tenant-sensitive.
Credentials are deliberately separated
- Full API key secrets are exposed only in their creation response.
- GitHub user OAuth access and refresh tokens are not persisted by installation setup.
- Run-scoped GitHub tokens are designed to remain in worker memory, outside child environments.
- Authorization metadata is subject to service-side secret redaction.
Repository and mission data still need protection
- Failed or interrupted workspaces may retain proprietary source until cleanup.
- Attachment storage needs private-bucket access controls and correct origin policy.
- Logs and telemetry must stay bounded and exclude secrets or unbounded command output.
- Backup, deletion, encryption, residency, and contractual retention depend on deployment and plan terms.
No trust by implication
What this page does not claim.
Absence of a claim is intentional. Ask for current evidence or contract language before using RustGrid in a regulated or availability-critical environment.
Certifications
No SOC 2, ISO 27001, or other security certification is asserted here.
Not claimedUptime
The operational health endpoint is not an uptime percentage, service-level objective, or service-level agreement.
Not claimedIndependent assurance
No penetration-test result, independent audit opinion, or vulnerability-free guarantee is asserted here.
Not claimedData guarantees
No universal residency, deletion deadline, encryption profile, or zero-retention promise applies across every deployment.
Not claimedSandbox universality
Production microVM isolation does not describe local execution, unsupported hosts, or a worker deployed without the required executor.
Not claimedResponsible disclosure
Report suspected vulnerabilities privately.
Do not post exploit details, secrets, or tenant data in a public issue. Email security@rustgrid.com with “Security report” in the subject and enough non-sensitive detail to identify the affected surface. If an intentionally public RustGrid repository enables GitHub private vulnerability reporting, that repository-specific channel is also appropriate. No response-time promise is implied.
Build on explicit boundaries
Autonomy needs controls you can inspect.
Review the architecture, verify your deployment responsibilities, and keep every agent action inside an observable mission history.