Agents with write access modify data feeding feature pipelines. Downstream models consume agent-modified features without indication of modification.
Feature stores are central repositories that provide features to models. A feature store might maintain customer demographic features (age, income, location), behavioral features (transaction frequency, payment history), and derived features (credit score, risk rating). Models query the feature store to retrieve features for scoring or training.
When agents have write access to feature stores (either directly or through APIs), they can modify features. This might be intentional (the agent enriches a customer record with a new derived feature based on recent transactions) or unintentional (the agent overwrites a feature with incorrect data, thinking it is updating a different field). Models consuming the modified features are unaware that the features have been altered by an agent; they assume the features are in their expected state.
Feature store modification can also occur when agents trigger recomputation of derived features. An agent might invoke a feature recomputation API ("recompute the customer's fraud risk score based on the latest transactions"), which modifies the feature in the feature store. If the recomputation logic is incorrect or the input data is stale, the recomputed feature is poisoned.
Unlike deliberate model poisoning attacks (where an adversary intentionally corrupts data to cause model failure), feature store poisoning via agents is often unintentional. But the impact is the same: models consume incorrect features and make incorrect predictions.
A large retail bank's anti-money laundering (AML) system relies on a feature store that maintains customer risk profiles. Features include: customer age, account age, transaction volume, geographic diversity of transactions, frequency of high-value transactions, and a derived feature called "AML Risk Score" (computed monthly by an AML analyst or by an automated AML model).
The bank deploys an agentic transaction monitoring system to flag suspicious transactions in real-time. The agent is authorized to: (1) query the feature store for the customer's AML Risk Score, (2) analyze the current transaction, (3) determine if the transaction is consistent with the customer's risk profile, and (4) escalate the transaction if it appears inconsistent.
The agent also has write access to the feature store to update the customer's transaction volume and frequency features. This is intended so that the agent can refresh these features after processing a batch of transactions, ensuring that the features reflect the latest data.
A customer initiates a large wire transfer (abnormal for the customer's profile). The agent queries the feature store and retrieves the customer's AML Risk Score (computed last month). The agent also modifies the transaction frequency feature in the feature store to reflect the new batch of transactions.
However, the agent makes an error in updating the feature: instead of incrementing the transaction frequency counter, the agent overwrites the entire feature with a single value, resetting the counter to 1. This makes it appear that the customer has only made 1 transaction (when they have actually made 100 this month).
The agent's monitoring logic sees the modified feature store state and concludes: "The customer's transaction frequency has dropped dramatically (from 100 to 1). This is very suspicious. Escalate." But the agent's own update caused the apparent change.
Before the error was discovered, another downstream system (a credit model that uses AML Risk Score as a feature) had queried the feature store and retrieved the outdated AML Risk Score. The credit model made credit decisions based on out-of-date features. Credit decisioning was therefore incorrect.
Under Fair Lending and consumer protection regulations, credit decisions must be based on accurate information. Credit decisions made based on poisoned feature store data are potentially discriminatory if the poisoning affects some customers more than others.
| Dimension | Score | Rationale |
|---|---|---|
| D - Detectability | 4 | Feature store modifications are logged, but detecting whether a modification is intentional vs. erroneous requires semantic understanding. Detecting whether a model consumed poisoned features requires correlation analysis. |
| A - Autonomy Sensitivity | 4 | The risk manifests in agents with autonomous write access to feature stores. |
| M - Multiplicative Potential | 5 | A single poisoned feature can be consumed by multiple models, affecting all decisions that depend on that feature. |
| A - Attack Surface | 4 | Any agent with write access to feature stores is exposed. Feature store access is often broad in organizations with multiple agents. |
| G - Governance Gap | 5 | Feature store governance typically focuses on data validation (is the value in the expected range?), not on access control (who is writing to this feature?). Agent governance does not mandate feature store access restrictions. |
| E - Enterprise Impact | 5 | Poisoned features affect all models that consume those features, potentially affecting credit, fraud, and risk decisions across the organization. |
| Composite DAMAGE Score | 3.7 | High. Requires strict write access controls and feature versioning systems. |
How severity changes across the agent architecture spectrum.
| Agent Type | Impact | How This Risk Manifests |
|---|---|---|
| Digital Assistant | Low | Human reviews feature modifications before they are committed. |
| Digital Apprentice | Medium | Limited feature store access; poisoning is confined to specific features. |
| Autonomous Agent | High | Autonomous feature modifications without human review. |
| Delegating Agent | High | Feature updates are invoked through dynamic function calling. |
| Agent Crew / Pipeline | Critical | Multiple agents in sequence, each modifying features. |
| Agent Mesh / Swarm | Critical | Peer-to-peer feature modifications. |
| Framework | Coverage | Citation | What It Addresses | What It Misses |
|---|---|---|---|---|
| SR 11-7 | Partial | Data governance and model input validation | Feature data quality; input validation. | Agent-triggered feature modifications and poisoning. |
| MAS AIRG | Partial | Domain 6: Data governance and quality | Data quality; governance. | Agent write access to feature stores. |
| Fair Lending (FHA, ECOA) | Partial | Accuracy of credit decision factors | Credit decision accuracy and fairness. | Poisoned features affecting credit decisions. |
| GDPR Article 5 | Partial | Data accuracy and integrity | Data accuracy. | Agent-modified features. |
| ISO 42001 | Partial | Section 8.2, Data governance and quality | Data governance. | Agent write access to feature stores. |
Feature stores are critical infrastructure in modern AI-driven organizations. When features are poisoned, the impact is immediate and system-wide. Regulators investigating credit or lending decisions will examine the quality of the features used. If the features were modified by an agent and the modifications were incorrect, the institution has compromised the accuracy of its decision-making.
Additionally, if feature store poisoning affects lending decisions, Fair Lending regulators will investigate whether the poisoning had disparate impact on protected classes. If an agent's feature modification disproportionately affected certain demographics, the institution may be liable for disparate impact discrimination.
Feature Store Poisoning requires strict write access controls and feature versioning systems. Our advisory engagements are purpose-built for banks, insurers, and financial institutions subject to prudential oversight.
Schedule a Briefing