Documentation menu
Security & data protection
Secrets, isolation, and the safety model around automation
An AI platform that can change production infrastructure has an unusually high bar to clear. This page is the honest version of that bar: what is stored, how it is protected, what the automation is technically capable of, and what evidence you can take to an auditor.
Secrets
Every credential — device passwords, API keys, SNMP communities, cloud tokens — is stored in Vault and referenced by an identifier. The secret itself is resolved at the moment of use and is not part of the object that references it.
| Property | Behaviour |
|---|---|
| Storage | Vault, not the application database |
| API exposure | Write-only — reads return a mask, and writing the mask back is a no-op |
| Logs and audits | Redacted by key path; secrets do not appear in detail fields or timelines |
| Agent visibility | Never in the model's context — the tool resolves the secret, not the agent |
The agent asks a tool to run a command against a device id. Credential resolution happens inside that tool, server-side. There is no prompt, tool result or transcript that contains the secret, which is also why a leaked transcript is not a leaked credential.
Isolation
- Workspace isolation — devices, tickets, credentials and audit entries are scoped to one workspace; queries do not cross the boundary.
- Per-workspace secrets and storage — one workspace's credentials cannot resolve another's.
- Networkless sandbox — agent-authored Python and shell runs in a sandbox with no network access at all, reached over a local socket.
- Typed tool calls for production — changes to real infrastructure go through the typed MCP tools, never through arbitrary code on a box you own.
Generated code is unpredictable by definition. Removing the network from its execution environment means the worst case is a failed computation, not an outbound connection to somewhere it chose. Production change happens through tools whose behaviour is fixed and reviewable.
The automation safety model
Four independent controls, in the order they would stop a bad action:
- 1Typed tools, not free-form access
The agent can only call declared tools with declared arguments. There is no path from a model output to an arbitrary command on an arbitrary host.
- 2Command classification
Risky command patterns are classified before execution, so a dangerous operation is recognised as dangerous regardless of how it was reached.
- 3Human approval
Mutating operations wait for a decision. The decision is attached to the exact plan, and rejecting it ends that attempt.
- 4Verification and rollback
The result is checked against the stated objective, and an automatic restore exists for the case where a verified change turns out to be wrong.
Bounded execution means a confused agent cannot loop indefinitely against production. When the budget is exhausted the run stops and hands back to a human — after a partial side effect the ticket goes to verification rather than continuing to act.
Transport and storage
- Transport — TLS for the UI, API and MCP endpoints. Certificate verification is enforced, with an explicit per-integration opt-out for self-signed consoles you own.
- Storage — databases and volumes are encrypted at the infrastructure layer.
- Session handling — short-lived access tokens with rotating refresh tokens, and the refresh token is HttpOnly so client-side script cannot read it.
- Password policy — enforced server-side, so the API cannot be used to set a password the UI would reject.
Abuse resistance
| Control | Applies to |
|---|---|
| CIDR and port allow-lists | Scanning and path-trace tools reach only permitted ranges and ports |
| Audited scanning | Every scan is recorded, so reconnaissance is attributable |
| Rate limiting | Webhooks, bot endpoints and MCP listings are limited to absorb burst load |
| MCP GET throttling | A reconnect loop cannot be turned into a request storm |
| Private-IP denial suppression | Unauthenticated internal probes do not flood the audit trail |
Compliance evidence
OrcaMonitor does not ask you to take our word for what happened. The audit trail is exportable with the fields a review needs — actor, action, target, decision and timestamp — and can be mirrored to a tamper-evident store for the period your policy requires.
- Refusals are recorded alongside successes, which is what access reviews actually ask for.
- Approvals are attributable to a named decision-maker, with the action they approved.
- Configuration changes carry a before-and-after diff.
- Exports can be filtered by date range and event type to match an audit window.
When reviewing this platform, request the audit export for a period and read the refusals. A log that only contains successful actions cannot answer whether a control works — it only shows that nobody was stopped.
OrcaMonitor documentation v1.0.0 · Report a problem
See every module, pricing tier, and deployment option on the OrcaMonitor overview.