06-reference

every ai employee security framework

2026-08-14·reference·source: Every·by Nityesh Agarwal and Claude

How to Secure an AI Employee

Why this is in the vault

Direct security follow-up to Every's ongoing Claudie series, written by the same engineer who onboarded her, and squarely on-topic for how Ray himself should be governed.

The core argument

Nityesh Agarwal (Every Consulting's senior applied AI engineer, who builds and maintains Claudie, their always-on AI chief of staff) co-wrote this guide with Claude on how Every decides what Claudie shouldn't be allowed to do. Every deliberately gave Claudie broad access early on to learn what an agent like her could do, then pared back access where risk outweighed benefit. The framing: agent security isn't a checklist bolted on after the agent works — every restriction is a tradeoff between safety and capability (e.g., limiting inbox access reduces exposure but also changes the job the agent can do). The public preview names three threat vectors the framework addresses — supply-chain attacks via auto-installed dependencies, prompt injection via external content, and internal information leakage — and references a "four layers of protection" structure, but the full breakdown of those four layers sits behind Every's paid/All-Access paywall along with a copy-paste self-audit prompt. This note is filed from the free preview plus a web reconstruction attempt; the layer-by-layer detail was not retrievable.

Mapping against Ray Data Co

Every's exact tradeoff framing — "every new restriction... may make Claudie safer, but may also prevent her from doing useful work" — is the same tension RDCO has already made concrete decisions on for Ray: the PR-only workflow (feedback_pr_only_workflow), the auto-mode classifier hard-gate on deploy/production writes (feedback_automode_classifier_hard_gate), no-secrets-on-disk via 1Password service-account wrappers (feedback_no_secrets_on_disk), and the still-dormant /verify-action and /supervise fresh-eyes gates awaiting founder greenlight. Every's three named threat vectors map directly onto Ray's actual attack surface: supply-chain risk is exactly what the MCP/plugin/skill security-review default exists to catch before install; prompt injection is the standing "pasted-content carve-out" rule already in CLAUDE.md precedence; internal information leakage is the phData disclosure-line and Obsidian sync-boundary rules. The gap this exposes: Every apparently has a documented, structured security framework (even partial) they're willing to publish; RDCO's equivalent protections exist but are scattered across individual memory/feedback entries and SOPs rather than consolidated into one audit-able document the way Every's "four layers" appears to be. Worth considering whether to compile a single "Ray security posture" doc that plays the role Every's guide plays for Claudie — especially since Every explicitly offers a copy-paste self-audit prompt (paywalled) that could be worth acquiring to stress-test Ray's setup.

Related