A domain-specific label extracted from traces to classify behaviour along a dimension built around the product or control question. It extends generic task or sentiment analysis by making logs useful for governance, compliance, or specialised operational review.
Expanded Definition
A custom facet is an analyst-defined classification layer applied to traces, events, or prompts so that activity can be reviewed through a business or control lens rather than a generic technical one. In practice, it sits between raw telemetry and governance reporting, allowing teams to tag observations against questions such as access misuse, policy exceptions, workflow stage, or control ownership. This makes the data more usable for security operations, audit preparation, and operational review.
The concept is closely related to metadata enrichment, but it is not the same as simply adding labels for convenience. A facet should be created to answer a repeatable governance question, and it should be defined consistently enough that results can be compared across time or systems. That distinction matters in environments where logs are being used for evidence, escalation, or compliance mapping. The closest standards alignment is with control-driven logging and monitoring practices in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need structured records that support oversight.
Usage in the industry is still evolving, and definitions vary across vendors that apply the term to observability, AI tracing, or governance dashboards. The most common misapplication is treating a custom facet as a free-form tag, which occurs when teams create labels without a stable control question or shared classification rule.
Examples and Use Cases
Implementing custom facets rigorously often introduces taxonomy maintenance overhead, requiring organisations to weigh better governance visibility against the cost of designing, reviewing, and updating the label set.
- A security team adds a facet for LLM application risk so trace records can be grouped by prompt injection, data exposure, or output misuse during review.
- An IAM team tags access-review evidence with a facet such as “privilege escalation path” to separate ordinary approvals from higher-risk entitlement changes.
- A compliance function applies a facet for “policy exception” to surface events that warrant manual inspection before an audit window closes.
- An operations team classifies workflow traces by “customer impact” so incident analysis can prioritise failures affecting regulated or high-value services.
- A platform team uses a facet for “control owner” to route observations to the correct accountable team without reprocessing the raw logs.
These examples show why custom facets are more valuable than generic filters: they convert telemetry into a reusable governance lens. Where traces are used in AI-enabled systems, the same idea can support structured oversight of model behaviour, especially when paired with guidance from NIST AI Risk Management Framework and internal review criteria. The more specific the question, the more defensible the facet becomes.
Why It Matters for Security Teams
Security teams need custom facets because raw logs rarely answer the questions that matter during investigations, reviews, or regulatory evidence collection. Without a consistent facet model, analysts spend time manually reclassifying data, which slows triage and makes reporting inconsistent across teams. For identity-centric environments, this becomes especially important when traces involve service accounts, API keys, delegated access, or agentic workflows, because the same event may need to be viewed through both operational and governance lenses.
Custom facets also help bridge technical telemetry and control language. That bridge is useful when security leaders need to show how an event maps to logging, access governance, or exception handling expectations in frameworks such as NIST AI Risk Management Framework and NIST SP 800-53 Rev 5 Security and Privacy Controls. The main risk is not the absence of data, but the absence of a shared classification model that turns data into evidence.
Organisations typically encounter the cost of weak facet design only after an incident review or audit request, at which point custom facets become operationally unavoidable to reconstruct what happened in terms the business can defend.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.AE-3 | Structured event classification improves anomaly detection and analysis of security events. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit event content and logging categories support traceable, reviewable records. |
| NIST AI RMF | AI RMF governance supports structured oversight of AI-related traces and outputs. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance benefits from trace labels that distinguish tool use and control points. | |
| NIST SP 800-63 | IAL2 | Identity assurance context can be enriched with facets for verification and account activity. |
Use consistent facets to classify events so analysts can spot unusual patterns faster.
