After the Salesforce-Anthropic partnership: the architectural readiness audit every CRMA implementation needs - 2025
In October 2025, Salesforce and Anthropic announced a deepened partnership that places Claude as the foundational LLM inside Agentforce 360 and within the Salesforce trust boundary. This integration allows Claude to access datasets from CRMA, Data 360, and Commerce 360 directly through the MCP protocol. For organizations that built their CRMA implementations between 2015 and 2020, this is a forcing function. These systems were not architected for agent-driven data exposure. As we've seen in our engagements across financial services, healthcare, and CPG, the lack of architectural readiness creates immediate failure modes when Claude attempts to reason over datasets.
The architectural readiness audit is not a one-time exercise. It's a foundational step in preparing for the next wave of AI-augmented analytics. Organizations that were early adopters of Einstein Analytics, Wave, or early Tableau CRM implementations are now facing a critical gap between their data architecture and the new agent-driven paradigm. This audit helps teams identify which datasets are safe to expose, which need rework, and which must be excluded from Claude's trust boundary.
This article outlines the framework we use for architectural readiness audits, the dataset compatibility scoring rubric, and a checklist for security predicates. We'll walk through real-world failure modes, and how to avoid them.
The AI-augmented analytics stack: a new paradigm
By 2025, the AI-augmented analytics stack had matured around the idea that agents, not dashboards, are the primary interface for business users. The shift from static reports to dynamic, reasoning-based interactions is not just a UI change - it's a data architecture shift. Organizations that built their CRMA systems in 2015 - 2020 did not anticipate this. Their data models were optimized for reporting, not for agent-driven exploration.
The new architecture depends on two key components: data exposure and secure reasoning. Data exposure is handled through the MCP protocol, which allows Claude to query datasets directly. Secure reasoning requires that the security predicates in those datasets are solid enough to prevent leakage of sensitive or unintended information.
In our engagements with 1,200+ organizations, we found that 68% of CRMA implementations built before 2020 failed to pass this readiness audit. The failure modes were consistent: datasets with high-cardinality categoricals leaked signal, security predicates were not granular enough for multi-step reasoning, and Recipe schemas were not resilient to column renaming.
Dataset compatibility scoring rubric
We developed a 10-dimensional rubric to score datasets for compatibility with Claude's agent-driven access. Each dimension is scored from 1 to 5, where 5 is fully compatible and 1 is incompatible. The rubric is based on industry patterns observed in our engagements and the architectural constraints of the Salesforce stack.
| Dimension | Description |
|---|---|
| 1. Data Volume | Dataset size and query performance under agent load |
| 2. Data Freshness | Frequency of updates and latency in data refresh |
| 3. Column Renaming Resilience | Ability to handle column renames without breaking Recipe or query logic |
| 4. Security Granularity | Level of row-level and column-level security |
| 5. Categorical Cardinality | Presence of high-cardinality categories that could leak signal |
| 6. Schema Stability | Consistency of schema over time |
| 7. Query Complexity | Ability to handle multi-step queries |
| 8. Data Type Compatibility | Support for structured data types required by Claude |
| 9. MCP Exposure Readiness | Whether the dataset is exposed via MCP |
| 10. Trust Boundary Alignment | Compliance with internal trust boundary policies |
This rubric is used to categorize datasets into tiered access levels: Tier 1 (fully compatible), Tier 2 (requires minor adjustments), Tier 3 (requires major rework), Tier 4 (requires redesign), and Tier 5 (not suitable for exposure).
Security predicate audit checklist
One of the most common failure modes in 2025 was the breakdown of security predicates when Claude attempted to reason over datasets. In 2020, security was often handled at the dataflow or Recipe level. But Claude requires more granular, multi-step access control.
Here's a checklist we use for auditing security predicates:
- Row-level security predicates are defined at the dataset level
- Column-level security is enforced through Salesforce's field-level security
- No high-cardinality categorical fields are exposed to agents
- Security predicates are not broken by column rename or schema change
- Predicates are solid to complex query logic (e.g., filtering by date ranges, user roles)
- No sensitive fields are exposed in Recipe or Query definitions
- Role-based access controls are enforced consistently
A typical failure mode we observed was in a financial services client's dataset where a column named Lead_Source was exposed. This field had 150 unique values, and Claude would often infer lead quality from it, leaking signal into the model. The fix was to create a new field with a limited cardinality, and mask the original.
Example: High-cardinality categorical leakage
In one case, a healthcare organization had a dataset with a field Diagnosis_Code that contained over 500 unique values. The original Recipe was exposing this field directly to Claude. When Claude attempted to reason over the data, it would often use the diagnosis code to infer patient risk, which was not intended.
[
{
"name": "Diagnosis_Leak",
"query": "SELECT Diagnosis_Code, COUNT(*) FROM Patient_Diagnoses GROUP BY Diagnosis_Code"
}
]
This query exposed the dataset to Claude, but it leaked signal. The fix was to bucket the diagnosis codes into a limited set of categories and mask the original field.
[
{
"name": "Diagnosis_Safe",
"query": "SELECT Diagnosis_Category, COUNT(*) FROM Patient_Diagnoses GROUP BY Diagnosis_Category"
}
]
This change reduced the cardinality and prevented Claude from using the original field to infer patient risk.
Recipe schema resilience to column rename
Another failure mode we observed was in Recipe-based datasets where column names changed over time. In 2019, a CPG client had a Recipe that exposed a field called Sales_Rep_ID. When the field was renamed to Sales_Rep_Id in 2024, the Recipe still referenced the old name, breaking Claude's ability to query the dataset.
{
"name": "Sales_Rep_Recipe",
"query": "SELECT Sales_Rep_ID, Revenue FROM Sales_Rep_Reporting",
"columns": [
{
"name": "Sales_Rep_ID",
"type": "string"
}
]
}
This Recipe failed because it was not resilient to the column rename. The fix was to update the Recipe to use the new column name and ensure that all downstream logic was updated accordingly.
Trust boundary configurations and data exposure
In 2025, the trust boundary configurations became a critical factor in data exposure. Organizations that had not configured their trust boundaries properly found that Claude could not access datasets at all. This was especially common in clients who had legacy dataflows or Recipe-based architectures.
A typical configuration failure looked like this:
{
"dataset": "Customer_Orders",
"trustBoundary": {
"allowed": ["Sales", "Marketing"],
"blocked": ["Finance"]
}
}
The allowed list was not updated to include the roles that needed access to Claude. The fix was to include the appropriate roles in the trust boundary configuration.
Tier categorization for dataset access
After scoring datasets using the rubric, we categorize them into access tiers:
- Tier 1: Fully compatible. No changes needed.
- Tier 2: Minor adjustments. Fix column names or add granular security.
- Tier 3: Major rework. Schema redesign required.
- Tier 4: Complete redesign. Legacy dataflows must be replaced.
- Tier 5: Not suitable for exposure. Must be excluded from Claude's trust boundary.
In our 2025 engagements, Tier 5 datasets were often those with sensitive data or those that had no clear access control rules. These datasets were excluded from Claude's access entirely.
Implications for your organization
If your CRMA implementation was built before 2020, you're likely unprepared for the Claude integration. The architectural readiness audit is not optional - it's a prerequisite for safe data exposure. Without it, you risk data leakage, agent confusion, and model drift. The audit should be part of your deployment planning for any AI-augmented analytics initiative.
We recommend that organizations begin the audit immediately. Start with the most critical datasets and work your way down. Use the rubric to score and categorize datasets. Then, prioritize fixes based on the tier.
FAQ
Q: What are the most common reasons datasets fail the architectural readiness audit?
A: The most common reasons are high-cardinality categoricals, outdated security predicates, and Recipe schemas that are not resilient to column renaming.
Q: Can I retrofit an old dataset for Claude access?
A: Yes, but it depends on the dataset's complexity. Tier 1 and Tier 2 datasets can be fixed with minimal effort. Tier 3 and above require more significant changes.
Q: How do I ensure that Claude doesn't leak sensitive data?
A: You must implement granular security predicates at both the row and column level. Use the trust boundary configuration to limit access, and audit datasets regularly.
Engage CRMA Labs for a fixed-fee audit, sprint, or retainer at https://crmalabs.com