06-reference/research

locked down corporate deployment playbook

2026-08-02·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
locked-down-deploymentagent-deployersop-decisionperimeterfde

The locked-down deployment playbook: write the SOP, skip the starter-kit — because the starter-kit does not exist

The question

Verbatim: "Extract a 'locked-down corporate deployment' playbook upstream from the phData constraint map (filesystem escape-hatch, federated-SSO secrets workaround, connector-blocked fallbacks) — pull into the agent starter-kit / a new SOP?"

This is follow-up #1 from [[2026-06-04-harness-patterns-ray-to-phdata-work-agent]]. It is a routing decision with four options: (a) starter-kit content, (b) standalone RDCO SOP, (c) both, (d) neither.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

Recommendation: (b) — a standalone SOP in 02-sops/, written this month, scoped as a constraint-to-posture decision tree. Not (a), not (c), not (d). Confidence: HIGH on the routing, MEDIUM-HIGH on the scoping.

(a) is not a live option and should stop being offered. The starter-kit is a scope document, not a repository — verified absent from both GitHub and disk this run. Routing content into it converts a real finding into a second unbuilt artifact. If the kit is ever built, the SOP is its natural source material; the dependency runs SOP → kit, never the reverse. That also disposes of (c), which spends real effort on a phantom container in order to avoid choosing.

(d) fails on the observed cost of not deciding. Four briefs across two months have each independently re-derived "extract the playbook," and the most recent one ([[2026-07-31-phdata-work-agent-comms-surface-decision]]) wrote a rule addressed to a document that does not exist. That is the concrete, measurable waste: the research loop keeps re-purchasing the same conclusion because there is nowhere to put it. An SOP is the cheap terminator for that loop — it gives every future perimeter finding a filing address, which is exactly what [[2026-05-10-harness-moat-two-layers-portability]] means by Layer-1 discipline accumulating.

Two things about the scope have to change from what the parent brief imagined, and they are the load-bearing part of this recommendation.

First, the SOP is a decision tree, not a workaround catalog. The parent brief treated the escape hatches as the asset. The web research says otherwise: the filesystem bypass is a defect the industry is closing, and a catalog of bypasses ages badly and reads as shadow-IT enablement to precisely the security-adjacent buyer RDCO wants. The durable asset is one level up — the perimeter determines the agent's shape, and here is how to read the perimeter and derive the shape. That framing survives the escape hatch being closed, because the closing of the hatch is just another perimeter fact that feeds the same tree. The seven rules the vault can already support, all generically stated:

# Rule Provenance
1 Posture before tooling. Enumerate what the perimeter forbids first; the agent's shape is an output of the constraint map, not an input. [[2026-06-04-harness-patterns-ray-to-phdata-work-agent]] ("the environment is the product")
2 Presence picks the comms surface. A co-located, session-scoped operator gets a notification hook plus a local state file. A channel is for an absent human. Never port wall-clock parking machinery to an agent whose operator is in the room. [[2026-07-31-phdata-work-agent-comms-surface-decision]]
3 Prefer file-based integration over connector-based — and treat that preference as time-limited. Blocked connectors frequently have a filesystem-shaped equivalent (desktop-sync clients, exports). Record the expiry risk explicitly: endpoint and gateway vendors are closing this path. [[2026-05-30-phdata-work-agent-setup-plan]]; Manifold gateway gap
4 Secrets: the principle ports, the mechanism rebuilds. Nothing on disk, always. But a vendor password-manager CLI can fail under federated SSO; fall back to the OS keychain or per-session interactive auth rather than weakening the principle. feedback_no_secrets_on_disk (memory); [[2026-06-04-harness-patterns-ray-to-phdata-work-agent]]
5 Decompose the auth paths — one federation failure does not imply another. A secrets-CLI that cannot handle federated login says nothing about whether the identity provider still issues ordinary OAuth tokens to a local script. Test each path separately before declaring a capability dead. [[2026-05-30-phdata-work-agent-setup-plan]] (the Google-OAuth-still-works finding)
6 The leash tightens with the confidentiality of the context. Read + draft only, human-gated egress, no public surface, hard context isolation from any other agent the operator runs. [[2026-05-30-phdata-work-agent-setup-plan]]; feedback_no_autonomous_external_email (memory)
7 A technical workaround is not an authorization. Egress is the governed boundary; a self-built agent is an unverified app to the tenant. The existence of a path does not create sanction, and the SOP must say so in its own voice. [[2026-06-01-phdata-dlp-governance-gate-personal-ai-agent]]

Rule 7 is what makes the document defensible rather than hazardous, and it should lead — not sit in a footer.

Second, the SOP must be honestly labelled reconnaissance-grade. The constraints were enumerated from a locked box, not encountered during a completed build. Marking each rule with an evidence tier (observed / enumerated / predicted) costs one column and prevents the document from laundering a prediction as a measurement — the exact failure the vault has logged before under feedback_calibrate_overconfidence (memory). It also lets the SOP upgrade in place as real deployments land, which is the whole point of a ratchet artifact.

Do not bundle the publish decision with the write decision. [[2026-06-05-compliant-work-agent-productizable]] and [[2026-06-19-phdata-experiment-fde-positioning-proof-point]] both routed this material toward Sanity Check, and that may still be right — but publishing requires a bridge story, and there is not one yet, because the deployment did not happen. Write the internal SOP now (reversible, in-niche, terminates the re-derivation loop, no confidentiality exposure); hold the public artifact until either a real in-perimeter deployment lands or the piece is reframed away from lived-experience credentialing toward the decision-tree method. Any eventual public version stays at the constraint-class level and passes feedback_employer_client_content_boundary (memory) plus a founder gate, per the existing standing rule.

Timing argues for now rather than later. The founder's title is now Forward Deployed Engineer, which makes deploying agents inside somebody else's perimeter the day job rather than a thesis. An SOP that answers "how do I read a perimeter and derive an agent shape from it" is a working instrument for that role, not just a positioning asset — and it is the in-niche expression [[2026-06-05-compliant-work-agent-productizable]] endorsed (a delivery sub-routine of the FDE wedge, sold to a buyer who can transact) rather than the standalone service it rejected.

Why this is in the vault

This closes follow-up #1 of [[2026-06-04-harness-patterns-ray-to-phdata-work-agent]] with a routing answer — SOP, not starter-kit — and supplies the reason the question kept recurring: the starter-kit that three prior briefs assumed as a destination was never built, so every extraction recommendation had nowhere to land. It also issues two corrections that other live documents depend on: the filesystem escape hatch is a closing window rather than a durable primitive, and the FDE proof-point brief's bridge-story claim outruns a deployment that never occurred.

Open follow-ups

  1. How fast is the filesystem/stdio bypass actually closing? Rule 3's expiry date is the single biggest determinant of the SOP's shelf life. Track whether macOS MDM and enterprise endpoint-management profiles are gaining agent-specific filesystem grants comparable to the Windows 11 agent-workspace model, and on what timeline. (macOS side: unverified this run.)
  2. Does an operator-side deployment genre emerge, or does the vendor corpus stay admin-only? If Anthropic or a major vendor ships guidance for the employee inside a perimeter they do not control, the differentiated slice closes. Re-scan the corpus in ~2 quarters.
  3. How does an operator-side perimeter playbook land with a security-adjacent audience — credentialing, or shadow-IT enablement? Rule 7 is the hedge, but the reception question is empirical: look at how comparable practitioner content on working within (not around) enterprise controls has been received, since it decides whether the SOP is ever publishable at all.
  4. What is the minimum evidence standard for calling a portability ledger "measured"? The vault currently holds a predicted port-vs-rebuild ledger being cited as a measured one. Defining the bar — what has to actually run before a row upgrades from predicted to observed — is reusable well beyond this SOP.

Rejected as non-research and routed elsewhere: writing the SOP itself and back-filling the setup plan's decision line are build tasks for the board; confirming the employer's Workspace edition, app-approval posture, or AI acceptable-use policy is blocked on corporate access RDCO does not have and was already logged as founder-side UNVERIFIED in [[2026-07-31-phdata-work-agent-comms-surface-decision]]; "test the playbook against a live corporate instance" is untestable without credentials.

Related

Sources

Vault (all also linked under Related):

Direct observation this run (not a citation — a check):

Web:

Sourcing discipline note: the Anthropic secure-deployment doc and the corporate-proxy guide were fetched and read in full this run. The Manifold, General Analysis, Northflank, IntuitionLabs and XDA items are from search-result summaries and are cited as corroborating context, not primary-text verification. The macOS-MDM half of follow-up #1 is explicitly unverified.