Security at Agent Control Room

Workspace boundary

Tenant isolation is the design premise

Agent Control Room is a multi-tenant service, but a request is resolved to one workspace before its data is read. Membership, role and workspace scope are then enforced again at the data layer. The product has no customer-facing view or policy path that intentionally spans workspaces.

Each workspace has its own address, members, roles, settings, API credentials, agent registry, policies, decisions, approvals and audit trail. Administrative operations are checked on the server and scoped to the workspace named by the authenticated request — not to a workspace identifier supplied unchecked by the browser.

Data architecture

Control data and policy evidence are deliberately separated

Not all security-relevant data needs to live in one system. Agent Control Room keeps the operational records needed to authenticate callers, coordinate decisions and enforce limits in its managed database, while the detailed policy and evidence record lives in a storage bucket dedicated to the workspace.

This is a security boundary, not just a storage choice. A compromise of the operational database would not by itself disclose the full rule set, context contracts, request context, decision rationale or audit history. A compromise of one workspace bucket would not provide another workspace’s records. The remaining metadata is still protected as sensitive: identifiers, action names, resource references and timestamps can reveal operational patterns even without payload content.

• Operational database

  Holds workspace settings, member identities and roles, hashed API keys, network restrictions, the agent registry, approval state, idempotency receipts, counted-grant events and a limited decision index. The decision index records identifiers, agent, action, resource reference, outcome, timing and the location of the detailed evidence; it does not hold the request context or decision rationale.

• Workspace evidence bucket

  Holds the active rule set and per-action context contracts, full decision evidence and the workspace audit trail as JSON objects. Buckets are resolved from the authenticated workspace record; callers do not choose an arbitrary storage location in a policy request.

• Customer-owned cloud storage

  Where required, the evidence bucket can sit in the customer’s own cloud storage account, with its region, retention rules and access controlled there. Google Cloud Storage is the connector available today, and S3-compatible storage is accommodated on the enterprise roadmap. Agent Control Room uses a credential scoped to that workspace’s bucket, which the customer can revoke. This keeps detailed policy logic and evidence inside the customer’s cloud boundary while the control plane retains only the operational records it needs.

Decision path

An agent cannot grant itself authority

The model proposes; the policy engine decides. A caller submits an agent identity, action, resource reference, a SHA-256 payload hash and the context facts used to judge that action. Agent Control Room does not receive or inspect the content represented by the payload hash. Context deliberately supplied for policy evaluation is separate and is retained in the workspace evidence record.

Rule evaluation is deterministic and replayable for the same governed request. Stateful controls are explicit rather than hidden: approval state, idempotency, revocation, rate windows and cooldowns are recorded and enforced around that evaluation.

• Typed context contracts

  Each action can declare the facts it accepts, their types and allowed ranges, and whether provenance or freshness metadata is required. Missing, malformed, stale or unlisted required context produces Not decided before a policy rule runs; it never falls through to permission. These checks do not independently verify who supplied a fact.

• Delegated authority only shrinks

  When a step is handed on from another agent’s grant, its place in the chain — depth, parent and origin — is derived from Agent Control Room’s own decision record, never from what the caller asserts. A delegated grant cannot outlive its parent, cannot reach an action the parent’s rule does not allow passing on, and cannot carry a larger numeric fact than the parent did. Revoking any grant in the chain invalidates every grant delegated from it. Circuit breakers fail closed: grants per delegation chain and per workspace are counted atomically, a crossed limit holds that chain or the whole workspace for a set period, and a count that cannot be checked refuses the step. Each grant’s Ed25519 signature also covers its parent, root and depth, so a delegated grant cannot be presented as a root grant, and a whole chain can be exported as a signed, metadata-only graph file that anyone holding the published key can check.

• Three policy outcomes

  A rule can allow, refuse, or ask a person first. An optional Complyee Policy Library reading can be recorded as advisory evidence, or configured as a restrictive gate on a locally allowed step. It cannot create an allow outcome, override a refusal or replace a required human decision.

• Human approval with separation of duties

  Approval requests are bound to the governed request. A rule can prevent the registered owner of an agent from approving that agent’s own step; the restriction is enforced on the server and blocked attempts are audited.

• Atomic limits

  Per-agent, per-action rate windows and cooldowns are claimed atomically when a grant is issued. Concurrent calls cannot each pass a stale counter, and an approval held for a person is checked again when its grant is claimed.

• Short-lived, payload-bound grants

  An allow outcome carries a signed grant covering the decision identifier, payload hash and expiry. Approval grants are single-use. The enforcement point can verify that the grant is live and belongs to exactly the payload it is about to execute; a different payload does not inherit the permission.

• Evidence, not an opaque verdict

  Decision records preserve the rule outcome, context validation, provenance, timing, approval lifecycle and grant binding needed to explain what happened. The database keeps a limited index for fast administration; the detailed evidence remains in the workspace bucket.

Shared responsibility

The trust boundary: your caller supplies the facts

Agent Control Room treats a service holding a workspace API key with policy.decide permission as a trusted policy enforcement point. It authenticates the key, applies its scope and network restrictions, checks the declared context contract, evaluates the workspace’s rules, and records the decision and supplied evidence. A signed grant authorizes the specific payload hash, but Agent Control Room cannot inspect that payload or independently establish whether a caller-supplied fact is true.

In particular, assertedBy and observedAt are supplied by the caller. Contract checks can reject an unlisted asserter or stale timestamp, but they do not authenticate the claimed source or prove when the underlying event happened. A compromised or dishonest key holder can submit false facts that satisfy a rule and obtain a grant. The decision trail supports review; it does not prevent this misuse.

The customer must issue policy.decide keys only to trusted server-side enforcement services, keep them out of agents and browsers, derive facts from authoritative systems rather than agent-generated claims, constrain key scopes and networks, rotate or revoke compromised keys, and verify each grant against the exact payload before acting. Where independently attested facts are required, do not rely on caller-supplied provenance alone; design an additional verification integration before using those facts to grant permission.

Optional integration

The Complyee Policy Library can advise or restrict — never grant

Agent Control Room supports a specific pairing with the Complyee Policy Library. It is not a generic endpoint contract for interchangeable policy libraries: the two services use an agreed request and assessment format, and a workspace administrator must configure the Complyee Policy Library gateway and API key before any consultation occurs.

For a consulted action, Agent Control Room sends the action key, the agent key, a decision correlation identifier, up to 40 supplied context facts and a bounded plain-language description — either supplied with the request or taken from the workspace action definition. Extra context fields may be included, so customers should treat every context value sent to Agent Control Room as eligible for that consultation. Agent Control Room does not send the payload hash or the document, prompt, message or other content represented by it.

• Advisory review

  The Complyee Policy Library is consulted after Agent Control Room has decided. The reading is retained with the decision and shown to a person reviewing it, but it cannot change the effect, signature or expiry.

• Restrictive gate

  A gate runs only after local rules have allowed the step and before limits are claimed or a grant is signed. A supports reading preserves that allow; requires approval holds it for a person; a prohibition, conflict, insufficient evidence, timeout or missing reading follows the administrator's fail-closed choice to hold or refuse. No reading can loosen a refusal or human hold.

• Stable approval evidence

  A repeated request for the same step can reuse the matching recent reading rather than call the Complyee Policy Library again. While an approval remains open, later calls reuse the reading recorded when it opened, and a resulting grant inherits that reading. Decisions identify gate-supported grants separately from human approvals, and the bounded decision export preserves that provenance without describing the Complyee Policy Library as the authority that granted execution.

Identity and access

Getting into a workspace

Human and machine access have separate credentials and controls. A browser session does not become an API credential, and an API key does not become a member session.

• Approved networks only

  A workspace can restrict browser access to approved public IP ranges. Requests outside those ranges are refused before access is established. Workspace addresses resolve to Agent Control Room's own edge worker first: it strips any caller-supplied location headers, forwards the visitor address it observed at the network edge, and issues a short-lived, signed cookie that binds that address to the workspace being visited. The application treats a network identity as trustworthy only when it carries one of these edge-issued proofs — and if a workspace has any network rule at all, a request without a provable address is refused outright, so a spoofable header can never satisfy an allow-list.

• Scoped API keys

  Programmatic access uses per-workspace keys with operation scopes, rate limits and optional per-key network ranges. Keys are stored as SHA-256 hashes, shown only when created, and rotated by creating a replacement and revoking the old key.

• Passwordless or enterprise identity

  Members sign in with a short-lived code sent to an approved company email address, or through the workspace’s identity provider. There is no reusable Agent Control Room password to phish or leak. Sign-in code requests are throttled per address and network.

• Domain and single sign-on enforcement

  A workspace controls which email domains may join. Single sign-on can be made mandatory, in which case the email-code path is refused on the server so the customer’s identity, MFA, conditional-access and deprovisioning policies remain authoritative.

• Server-enforced roles

  Workspace member, workspace administrator and platform administrator are distinct roles. Privileged actions check those roles on the server and role changes are written to the workspace audit trail.

Session control

Sessions end when policy says they end

Each workspace can set an idle timeout and an absolute maximum session length. The maximum is checked on protected server requests, not only in the browser, so modifying an open tab cannot extend the session beyond workspace policy.

Workspace administrators can revoke one member’s sessions or every session in the workspace. Removal and erasure also revoke the affected member’s sessions, and revocation is recorded. Ending an Agent Control Room session does not end a session at the customer’s identity provider; complete offboarding still requires disabling the identity there, while removing workspace membership prevents re-entry here.

Platform safeguards

Credentials and edge protection

Service credentials are kept in encrypted secret storage outside the codebase. They are not shipped to the browser or rendered in the interface, and server-side code reads them only for the operation that needs them. Access between services is scoped to the narrowest practical role, including one bucket credential per workspace where customer-owned storage is used.

Traffic is encrypted in transit and served through a global edge network that absorbs volumetric and denial-of-service traffic before it reaches the application. Workspace addresses are served through Agent Control Room's own edge routing layer, and a workspace subdomain reaches the application only through it: the worker removes untrusted location headers from incoming requests, asserts the visitor's real address and its own edge credential, and the application verifies that credential rather than trusting any header a caller could set. Workspace network rules can therefore stop unapproved traffic at the edge and be enforced against a network identity the caller cannot forge.

Evidence and oversight

Security configuration and governed activity stay inspectable

The workspace audit trail records security and governance events in the workspace’s own bucket: authentication outcomes, access and setting changes, API-key administration, agent registration, policy changes, decisions, approval activity, revocation and exports. There is no cross-workspace fallback sink if a workspace bucket cannot be resolved.

Administrators can inspect recent decisions and their approval lifecycle, export a live security-posture checklist, and download a machine-readable system record and dated dossier. These records support internal assurance, CMDB and AI-system inventory work; they describe the deployed configuration and evidence, but do not certify compliance.

Resilience and lifecycle

Recovery, location and deletion

The operational database runs on managed infrastructure with automated backup and recovery capability. Workspace buckets can use object versioning, soft delete and lifecycle rules; in a customer-owned storage account, those controls and their retention periods remain under the customer’s administration. Backups are for service recovery, not a way to restore customer data deliberately deleted from the live service.

A workspace’s policy rules, context contracts, detailed decision evidence and audit trail can be provisioned in a dedicated EU or US evidence-storage region, selected and fixed during onboarding; customers using their own cloud storage choose and control that region themselves. Core account, workspace, membership, role, configuration, key, approval, idempotency, counted-grant and limited decision-index records remain in our managed, EU-hosted application database. We state that distinction explicitly so a security review can assess the complete data path rather than treat “regional hosting” as a claim about every service record.

Workspace deletion removes the objects and versions in its evidence bucket, then the bucket, workspace-only sign-in accounts and the workspace’s database records. The operation records a deletion receipt outside the removed bucket so completion remains provable after the workspace and its own audit trail are gone. If customer-owned credentials have already been revoked, Agent Control Room reports that it cannot remove those customer-controlled objects rather than claiming deletion succeeded.

Assurance

Where we are on certifications and availability

Agent Control Room is not currently SOC 2 or ISO 27001 certified, and we do not imply otherwise. The controls on this page are product controls available today. We can complete security questionnaires (SIG, CAIQ or your own format), discuss a data processing agreement — including US state privacy terms — or a customer security schedule, and walk a customer’s security function through the implementation under NDA.

The service uses a global edge network and managed infrastructure, but standard plans carry a reasonable-efforts availability commitment rather than a contractual uptime guarantee. Contractual service levels, security obligations and sub-processor notice terms must be agreed in the customer contract when required.

Responsible disclosure

Reporting a vulnerability

If you believe you have found a security weakness, write to the security address below with enough detail for us to reproduce it. We acknowledge reports within two business days and keep reporters updated through resolution. Please allow a reasonable remediation window before public disclosure, and do not access, alter or retain data that is not yours while investigating.