Your CLAUDE.md probably knows more about your AEM stack than your wiki does — who's reviewing it?
Been thinking about this a lot lately, and curious how other AEM teams are approaching it.
For years, we've poured effort into hardening the perimeter around our AEM environments — VDIs, VPNs, SSO, locked-down repos, strict PR gates. Classic castle-and-moat thinking: keep the outside out.
But here's what's nagging at me: with AI coding agents now part of the daily workflow, files like CLAUDE.md, AGENTS.md, and .cursorrules have quietly become some of the most information-dense documents in the repo. Dispatcher configs, content fragment models, component architecture, business logic — plain-English descriptions of exactly how the system works.
And that's the actual problem: these files usually don't get the same treatment as code. They're committed casually, reviewed loosely (if at all), and often live at the repo root where any contributor — human or AI agent — can read them. Unlike obfuscated code or config buried three folders deep, this is a plain-English map of your system: auth flows, integration points, internal naming conventions, business logic — all in one place. Old-school breaches usually meant piecing together fragments from scattered code, configs, and tribal knowledge. Here, one or two files leaking is enough to hand someone the whole picture at once. No assembly required.
It also opens a second door: prompt injection. If an agent reads these files as trusted instructions, a poisoned line slipped into a context file, a comment, or even content the agent ingests along the way could quietly redirect what it does next — with the same read/write/orchestrate privileges we handed it for legitimate work.
It's the old castle problem in a new form: we locked the heavy front gates, but left the blueprint sitting on the hallway table — and it turns out one page of that blueprint tells you everything.
A couple of things I'd genuinely like to hear from this community on:
Who's reviewing these files? Are your security teams or PR processes treating changes to AI context files with the same scrutiny as production code — or are they still waved through as "just documentation"?
Where do you draw the line? How much system topology, folder structure, and business logic do you let a context file hold before it effectively becomes your enterprise blueprint, written in plain English, sitting in your repo — and a single point of failure if it leaks?
Not trying to be alarmist — AI agents genuinely make us more productive, and context files are a big part of why. But I don't think we've caught up on the governance side yet. Would love to hear how your team is handling this, or if this is a non-issue and I'm overthinking it.