Ghost Proxy is a large, private purple-team lab with ten modules, most of them offense-named: Threat Simulator, Neural Lab, Deception Engine, and others that don't belong in a compliance writeup. This report is scoped to one corner of it on purpose: the GRC Command Center, which models enterprise governance work, data classification standards, Just-In-Time admin access, retention policy, SOC 2 mapping, not attack tooling.
Scope and Objective
The target is src/components/GovernanceCenter.tsx's classification-scan action and the shared service it depends on, src/services/warningGate.ts. The repo's own docs/IMPLEMENTATION_PUNCHLIST.md is explicit that GRC Command Center runs on "local policy fixtures only" and does not push policy changes or contact a real scanner. That's an honest scope claim worth taking at face value rather than re-litigating. What it doesn't say outright is whether the one real mechanism sitting underneath every fixture button, the warning-and-acknowledgement gate, actually behaves the way a compliance control should: no record without consent, a structured record when consent is given.
That's the one claim this report checks: does confirmLocalPlanningAction, the function GRC Command Center's INITIATE_CLASSIFICATION_SCAN button calls, produce a real acknowledgement object with a timestamp and a purpose tag when the operator accepts, and produce nothing, no record, no side effect, when they decline.
Findings
The function exists, is called from the real UI code path, and does what the punchlist implies. Reading GovernanceCenter.tsx:
const runClassificationFixture = () => {
const acknowledged = confirmLocalPlanningAction({
action: 'Run local classification scan fixture',
context: 'This opens a classification exercise around the displayed example incident.',
});
if (acknowledged) {
setSelectedCategory('Classification');
alert('CLASSIFICATION_FIXTURE_READY: Review mapped controls and add real scanner integration from the punchlist.');
}
};
And the gate itself, in warningGate.ts:
export function confirmLocalPlanningAction(params: { action: string; context: string }): WarningAcknowledgement | null {
const accepted = confirmWarning({
title: 'LOCAL PLANNING WARNING',
action: params.action,
body: `${params.context}\n\nThis records or displays planning context only. It does not deploy, remediate, scan, or call a provider.`,
});
return accepted
? {
confirmed: true,
acknowledgedAt: Date.now(),
purpose: 'LOCAL_PLANNING',
action: params.action,
}
: null;
}
That return type, WarningAcknowledgement, is the shape of an access-audit-trail entry: a confirmed flag, a timestamp, a purpose category, the action text, and an optional target. It's the same primitive the Privacy Engine module calls for its own local fixture runs, under a sibling function (confirmLocalFixtureAction), so the mechanism isn't a one-off, it's the shared least-privilege gate for every local-state-changing action across both modules. Reading the code is one thing. Running it is another, so that's what the verification step does.
One honest secondary observation, not a bug: the module's "Just-In-Time Access Fixture" panel shows a static "Elevated Admin (Prod)... Expires in 59:52" line. It's hardcoded text, not a live countdown, no timer backs it. That matches the punchlist's own framing (fixture, not enforcement) and isn't misrepresented anywhere in the UI copy, so it's reported here as confirmation the scope claim holds, not as something broken.