ApexCorpWhat is enforced, and what is not yet true
Autonomous agents with tool access are a security question before they are a product question. Everything in the first section corresponds to code with a test on it. The last section is the part most security pages leave out.
Enforced in code
- Agents cannot leave the project root
- Every agent-supplied path is resolved and checked twice — lexically, then again after resolving symlinks, because a plain prefix test accepts /app-evil next to /app. Percent-encoded separators and null bytes are refused rather than decoded. Tested against hostile input.
- Commands run against an allowlist, never a blocklist
- npm test/run/ls/why, git status/diff/log/show/blame/ls-files, node --version. Shell operators are refused, and commands execute without a shell so the allowlist cannot be re-parsed around.
- No agent can send anything outward
- Outward-facing roles receive a draft capability and no send capability. No role in the system holds one — a test asserts that no role anywhere in the catalogue can send. Commits, pushes, PRs and messages become approval-queue items.
- Nobody approves their own work
- The function that approves a company structure takes a person’s name, not an agent id, so the Manager cannot sign off on the org it proposed. Memory approval checks that approver and proposer differ before it checks anything else.
- Spend is metered and capped
- Per run and per day, against real token pricing. Crossing a ceiling halts every agent and files a note rather than continuing quietly.
- Runs are bounded
- A hard iteration cap per run, and a concurrency ceiling so only a fixed number of agents run at once. The kill switch is checked between steps and halts everything immediately.
Your model keys
- Where keys live
- In the orchestrator process’s environment, loaded from a .env file on the machine you run it on. They are never sent to the browser.
- What the control panel can see
- Whether each provider is configured — a boolean. The endpoint that reports this has no field capable of carrying a key value, and a test asserts on the raw response body that no secret appears in it.
- What the panel cannot do
- Submit a key. There is deliberately no write path: an unauthenticated localhost endpoint that persisted secrets to disk would be a worse hole than editing a file is an inconvenience.
- Who your prompts reach
- Your chosen model provider, under your own account and their terms. We add no intermediary of our own and do not retain prompt content beyond what the activity log needs.
Not yet true
Stated plainly, because these are the claims a reader cannot check from outside and the ones a vendor is most tempted to fudge.
- There is no SOC 2, ISO 27001, or third-party penetration test to report. The product is early and claiming otherwise would be inventing an audit. If you need one before you can buy, tell us — it moves up the roadmap when a real customer needs it.
- Multi-user access control and SSO are Enterprise-tier work, not yet generally available. Today the control panel assumes a single operator.
- Encryption at rest covers model credentials. The task, note and memory store relies on the encryption of the underlying volume rather than application-level encryption.
- There has been no third-party security review. The properties above are enforced in code and covered by an automated test suite, and we will walk you through that evidence under NDA — but evidence reviewed by us is not the same thing as an audit by someone else.
Reporting a vulnerability
If you find something, please report it privately before disclosing it publicly, using the address on the contact page. Include what you did, what happened, and what you expected — a reproduction is worth more than a description. We will acknowledge within two working days.
There is no bug bounty yet, and we would rather say so than advertise one we cannot fund. Report anything real and we will credit you publicly if you want that.