PostHog makes access resolution more specific and tightens MCP intent capture

What changed

PostHog published two governance-related changelog items on 11 September. Access control now uses the most-specific rule, so a member-specific decision takes precedence over broader role or project access. PostHog also says intent capture for its MCP server now redacts common structured PII before analytics events are recorded.

Sources: PostHog official changelog

Specific access rules can express deliberate exceptions

PostHog's example is a member who can be denied access even when a role or the project default grants broader access. This changes how overlapping rules resolve; it does not automatically prove that every existing policy now reflects the business's intended data boundary. Administrators should inspect effective access after the change, especially for projects containing customer, revenue or experiment data.

A useful review starts with the expected decision for named test users: project administrator, analyst, external collaborator and an explicit exception. Compare the observed result with the declared policy and retain who approved each exception. Avoid granting a larger role simply to restore access to one resource.

Access review should include downstream paths

A user who cannot open a project directly may still receive data through an export, service account, warehouse query or connected application. Conversely, an integration can fail when its human owner loses access. Build an access map that includes people, roles, API keys, service accounts and scheduled destinations rather than reviewing the UI alone.

Test a denied case without attempting to bypass the restriction. Confirm that audit records show the relevant decision and that the exception owner knows how to request an appropriate change. The objective is reproducible access, not the largest possible set of users.

MCP intent capture now has a narrower data path

PostHog says structured PII including email addresses, phone numbers, IP addresses, card patterns and US Social Security numbers is redacted from captured MCP intents in its JavaScript and Python libraries. Intent capture can help teams understand the questions asked of an agent interface, but those questions can themselves contain customer or employee data.

Redaction lowers risk for the listed patterns; it is not a complete data-classification guarantee. Free text can contain names, contract details, uncommon identifiers or context that remains sensitive after a pattern is removed. Teams should define what prompts may be collected, who can inspect them and how long the events are retained.

Verify rather than infer the redaction boundary

Create synthetic test prompts containing each documented pattern, nearby punctuation, formatted and unformatted variants, and business-specific identifiers. Inspect the actual analytics event and confirm that no raw prompt is retained in another log, trace or error destination. Do not use real customer or payment data for the test.

Record the library version and configuration under test. If an application uses a different client, proxy or custom capture path, the changelog entry may not describe that path. A safe result is specific: the tested event removed the tested synthetic values in the tested version.

One control model for product data and agents

The two updates address different stages of the same operating chain. Access rules determine who or what can reach a data surface. Intent handling determines what the system records when that surface is used. RevOps teams connecting product behavior to customer workflows need both controls, plus field authority at the destination.

Before an agent-derived insight becomes a CRM field or lifecycle action, preserve the source project, query or intent version, entity match, reviewer and write result. A narrowly authorized query can still produce an inappropriate downstream action if identity or customer eligibility is wrong.

A practical change review

Inventory member-level exceptions and service accounts, run the effective-access test set, then validate synthetic PII redaction in every deployed MCP client. Review exports, warehouse connections and destination write-backs as separate paths. Route unexpected access or retained data to a named owner rather than silently adjusting the test.

After the first pass, remove one permission from a synthetic user and rotate one test service credential. Confirm that scheduled queries, dashboards and agent calls fail or recover in the expected way and that the owner receives an actionable signal. This changed-state test is important because a static access review can miss dependencies that appear only when a role, member exception or credential changes.

PostHog has made two controls more explicit. The release does not establish that an organization's overall data governance is complete. That conclusion requires evidence across identity, access, capture, retention and downstream activation in the team's own stack.