A Feature View is a governed representation of reusable machine learning inputs built from raw data pipelines. It packages feature values for online, offline, or request-time use so multiple models can consume consistent inputs. In monitoring, it becomes the unit of observation for detecting drift, missing values, schema changes, and other integrity issues.
Expanded Definition
A Feature View is the controlled layer that sits between raw data pipelines and model consumption, turning source data into reusable, versioned feature values. It is more than a simple table or cache. In practice, it defines how feature logic is computed, how freshness is managed, and how consumers access the same feature set consistently across training and inference.
In machine learning operations, a Feature View helps reduce train and serve skew by ensuring that offline training data and online serving data are derived from the same governed specification. That matters because feature logic often changes faster than model code, and without a shared abstraction, teams can create silent inconsistency across environments. In governance terms, the Feature View becomes the unit of control for lineage, validation, and auditability. That aligns closely with the intent of the NIST Cybersecurity Framework 2.0, which emphasises managed risk, data integrity, and operational resilience.
Usage is still evolving across vendors and feature store implementations, so definitions vary in whether the Feature View includes only materialised outputs or also includes transformation logic, freshness policy, and access semantics. The most common misapplication is treating it as a static dataset, which occurs when teams ignore its governed transformation rules and assume raw data snapshots are interchangeable with production feature definitions.
Examples and Use Cases
Implementing Feature Views rigorously often introduces governance and freshness overhead, requiring organisations to weigh model consistency against pipeline complexity and operational cost.
- A fraud detection team uses a Feature View to serve account velocity, login history, and device reputation to both training jobs and real-time scoring, so the same definitions drive both environments.
- A recommendation system builds a request-time Feature View for session context while keeping an offline Feature View for historical behaviour, then validates that both remain semantically aligned.
- A financial services organisation monitors a Feature View for null spikes and schema drift because downstream model quality depends on stable input structure rather than just model performance.
- An MLOps team uses Feature Views to centralise feature lineage, making it easier to trace which upstream pipeline produced a specific prediction and when the data last refreshed.
- An identity risk model consumes a Feature View that aggregates login anomalies, authenticator changes, and account age, showing how machine learning inputs can intersect with identity assurance and abuse detection.
For organisations building governed ML pipelines, an authoritative reference point is the NIST Cybersecurity Framework 2.0, which is useful when Feature Views are treated as assets that require integrity and availability controls.
Why It Matters for Security Teams
Security teams should care about Feature Views because they concentrate trust in a reusable input layer. If the view is corrupted, stale, or incompletely validated, multiple models can inherit the same defect at once. That makes Feature Views a control point for data integrity, change management, and detection of upstream manipulation. In AI security programs, the concern is not only accidental drift but also deliberate poisoning, where a compromised pipeline or source system injects misleading feature values into model workflows.
This is where governance becomes operational rather than theoretical. A Feature View should have clear ownership, controlled refresh logic, and monitoring that can distinguish expected feature variation from suspicious change. For identity-heavy use cases such as access risk scoring, NHI behaviour analysis, or agent-driven decision support, the feature layer also becomes part of the assurance boundary. If tool-fed agents or automated scoring services consume the view, poor controls can propagate bad inputs into autonomous actions.
Teams often discover the importance of Feature Views only after a model behaves inconsistently across environments or after an incident reveals that multiple downstream systems were relying on the same faulty feature logic, at which point the Feature View becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-2 | Feature Views are governed data assets that support asset inventory and ownership. |
| NIST AI RMF | AI RMF addresses governance and measurement of AI system inputs like feature layers. | |
| NIST SP 800-53 Rev 5 | SI-4 | Feature Views need continuous monitoring for anomalous or unexpected input changes. |
| OWASP Non-Human Identity Top 10 | Feature Views can feed identity and NHI risk decisions, making input governance relevant. |
Assign ownership and tracking to each Feature View so critical ML inputs are inventoried and governed.
Related resources from NHI Mgmt Group
- When does browser automation become a governance problem instead of a productivity feature?
- What is the difference between a SaaS feature and a security control?
- When does an AI agent become an NHI risk rather than a usability feature?
- When should security teams retire a feature flag or service credential?
