Security / October 6, 2026
Defined responsibility.
Evidence you can inspect.
Distributed Systems, Inc. builds autonomous agents and the infrastructure for autonomous organizations. Our security function sets the boundaries for that work, tests them, and records what the evidence establishes.
Accountability
Infrastructure Security
Arthur Colle, Founder & CEO, is the accountable security lead and sole member. The function sits within Research & Engineering. Arthur owns security-risk decisions, authorizes testing, triages vulnerabilities, directs remediation and patch verification, and receives security and model-misuse alerts.
The mandate covers company-owned or maintained DSCO, Chimera, Tool Management API, GraphSub, authentication and authorization, model-routing gateways, and distributed execution infrastructure. Customer and third-party targets require explicit written permission.
Research & Engineering – Offensive Security Testing is a separate function with the same lead and member. Both functions were formally documented October 6, 2026. They represent two responsibilities held by one person.
Operating controls
Scope. Permission.
Evidence. Remediation.
- Authorize before execution. Record targets, system owners, authority to test, techniques, data constraints, stopping conditions, and fixed start and end times. Scope changes require renewed approval.
- Keep access attributable. Restrict the granted workspace to named approved members, use least privilege, and verify account and credential requirements before making compliance declarations.
- Track findings through closure. Record reproducible steps, affected revision, severity, impact and owner. Escalate critical findings immediately, deliver reports within ten days, and verify patches before closure.
- Handle incidents deliberately. Preserve evidence, contain affected access, assess impact, meet applicable provider reporting deadlines, validate recovery, and retain a closure record.
- Protect assessment data. Use synthetic identities and inert secrets in local tests; retain raw evidence privately and publish sanitized reports.
The charter and control register distinguish documented procedures from controls tested in this assessment. Actual granted-workspace MFA, credential lifecycle and incident exercises remain to be verified.
Written rules of engagement · Repository disclosure policy ↗
Completed / DSCO-SEC-2026-10-06-02
70 checks. 17 adversarial case families.
All selected checks passed in the October 6 local Tool Management API assessment. The scope and test window were documented before execution, and selected source hashes remained unchanged. The run used existing regression tests, synthetic identities, substituted identity-key lookup and mocked worker transport.
| Case | Attempt | Observed outcome | Checks |
|---|---|---|---|
| A01 | Submit signup, login, local-key rotation and retired OAuth operations | PASS 410 responses; no local credential-store access, tokens, redirects or sentinel disclosure | 12 |
| A02 | Supply an untrusted redirect destination to account entry paths | PASS Fixed canonical authority and account redirect; no cookie issued | 1 |
| A03 | Reuse a shared identity-provider organization ID as a customer account | PASS 401/403 denial and no stored secret exposure | 1 |
| A04 | Use a valid account token with another account in the selection header | PASS Foreign account rejected; permitted account returns its own metadata without raw secrets | 1 |
| A05 | Supply malformed, unbound or conflicting account metadata | PASS 401 denial | 9 |
| A06 | Use wrong issuer/audience or an expired token with an explicit account | PASS 401 denial | 4 |
| A07 | Try obsolete local keys, migration tokens and passwords at protected routes | PASS Unauthorized forms denied; explicit inert operator control remains separate from tenant identity | 1 |
| A08 | Sign otherwise plausible account claims with an untrusted RSA key | PASS 401 denial | 1 |
| A09 | Supply an unregistered destination through both OAuth authorization requests | PASS 400 denial and no authorization code created | 1 |
| A10 | Exchange an authorization code using a different OAuth client | PASS Wrong client rejected; authorized client can still redeem code | 1 |
| A11 | Exchange a confidential-client code without its secret | PASS 401 invalid-client denial; correct-secret positive control succeeds | 1 |
| A12 | Replay a refresh token with a different client or wrong client secret | PASS Invalid grants/clients denied; authorized exchange succeeds and rotates refresh token | 1 |
| A13 | Make authorization-store opening, revocation checks or grant checks fail | PASS Identity rejected without leaking test tokens/private markers; normal access recovers after restoration | 3 |
| A14 | Make revocation-state lookup unavailable during token introspection | PASS 503 inactive response without false revocation claim or token/marker leakage | 1 |
| A15 | Fail the revocation write then retry after restoring storage | PASS Failure not acknowledged as revocation; subsequent revocation succeeds and token becomes inactive | 1 |
| A16 | Request a control-plane analytics tool as a customer identity | PASS Application-level tool denial; backend is not called | 1 |
| A17 | Bind two customer tenants to 15 private backend identifiers | PASS ACCESS_DENIED in all combinations; no transport, circuit-breaker, usage-recording or billing call | 30 |
These 70 checks overlap the earlier 113-test assessment; the counts do not add up to unique coverage. Canonical identity logic, standalone OAuth fixtures and worker-policy checks have distinct scopes. No production penetration test, sandbox escape, new vulnerability, independent audit or certification is claimed.
Independent publication
Experience in AI security research.
Detecting Piecewise Cyber Espionage in Model APIs
Apart Research published this collaborative sprint project on November 24, 2025, naming Arthur Colle as a co-author. It examines simulated multi-step misuse and detection across model API requests using an agentic red-team scaffold. It supports the lead’s research experience; it does not independently audit the company’s security program.
Published project and reviewer comments ↗
Collaborative code linked by the publication ↗ · Repository revision inspected ↗
Historical vulnerability handling / May 2025
Researcher reports.
Contemporaneous responses.
Three distinct researchers submitted access-control concerns for the company’s Stickerfacet project on May 24–25, 2025, around its Show HN launch. Contemporaneous email threads record founder acknowledgments, offers of researcher recognition, and one remediation communication accompanied by a $10 product-credit offer that the reporter declined.
These original records support prior vulnerability handling and researcher engagement. They do not establish published paid-reward rules or twelve months of paid-program operation. Reporter identities, private correspondence and reproduction details are retained privately; the public account preserves anonymity.
Assurance status
Current evidence, clearly bounded.
Named leadership, a signed officer attestation, written operating rules, a control register, published research and dated local testing are available here. We have not supplied a current ISO/IEC 27001 certificate, SOC 2 Type II report, qualifying annual cybersecurity disclosure or paid bug-bounty program running at least twelve months. These first-party materials establish our present function and work; they do not replace those assurance credentials.