Teams should classify a system by what it does, not by what it is called. If it uses natural language to sustain an adaptive, human-like relationship across multiple interactions and meet a user’s social needs, it should be treated as a companion chatbot for scope analysis, even when it sits inside a broader product.
What makes a companion chatbot a companion chatbot in scope terms?
A companion chatbot is defined by behavior and user experience, not by branding or where it appears in a product. The classification question is whether the system sustains an ongoing, adaptive, human-like relationship and is used to meet social or emotional needs. If those traits are present, teams should treat it as in scope even when it is only one feature inside a larger app.
This matters because scope analysis should follow the actual interaction model. A chatbot that is merely informational, transactional, or narrowly task-based is different from one designed to simulate companionship, remember prior exchanges, and encourage repeated personal engagement.
How teams should decide scope when the chatbot is embedded in a broader product
Look at the function the user experiences, not the product category the vendor uses. If the companion behavior is a material part of the system, the broader platform wrapper does not remove that scope. In practice, teams should assess the conversational flow, personalization, persistence across sessions, and whether the system is positioned to build dependency or intimacy.
That distinction also affects how you document the system boundary. A companion chatbot can be a module inside a social app, wellness tool, gaming product, or customer platform, but the scope analysis should isolate the companion function and evaluate its distinct risks, disclosures, controls, and operating assumptions.
For a practical framing of companion-app risk, teams can use AI Companion App Privacy and Safety Guide to separate the companionship layer from the surrounding product features and user populations.
What evidence shows the system belongs in companion-chatbot scope?
The most useful evidence is observable product behavior. Teams should test whether the system remembers prior chats, adapts tone over time, encourages return visits, presents itself as emotionally responsive, or is marketed as a friend, partner, confidant, or support companion. Those signals matter more than whether the underlying model is general purpose or the UI is embedded in another service.
It is also important to review the system’s data handling and access paths. Companion systems often rely on session histories, saved preferences, profile data, and support tooling, which means scope decisions may change once the team sees what data the chatbot can access or expose. A product that looks harmless on the surface can still become high-scope if its conversation history, account data, or moderation tools are widely accessible.
Teams assessing whether the chatbot boundary has been drawn correctly should compare it with Public AI Chatbot Incident Playbook, especially where the companion experience has support workflows, escalation paths, or a kill-switch requirement.
Risk and Threat Considerations
Companion chatbots create risk when teams under-scope them as “just a feature” and therefore miss the privacy, safety, and trust consequences of sustained relationship-building. The main failure mode is boundary confusion: users may disclose sensitive personal information, rely on the chatbot for emotional support, or assume a level of care and accountability the system cannot provide.
Failure mechanism: The system is treated as a generic chatbot or marketing feature, so product owners omit companion-specific controls, disclosures, monitoring, and escalation handling even though the conversational design encourages repeated personal engagement.
Impact: Mis-scoping can lead to weak privacy controls, poor incident handling, unsafe user reliance, and regulatory or legal exposure if the product’s actual behavior resembles a companion service rather than a simple utility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | PL-2 — System and Communications Protection Policy and Procedures | Companion chatbot scope depends on documenting the system boundary and intended use. |
| RA-3 — Risk Assessment | Companion behavior changes privacy, safety, and legal risk that should be assessed. | |
| Recommendation — Define the companion chatbot boundary and scope it in policy and architecture documentation. Assess relational and disclosure risks before approving the chatbot for deployment. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | User disclosures and conversational content may require classification within scope decisions. |
| Recommendation — Classify chatbot conversation data and apply handling rules that match its sensitivity. | ||
| NIST CSF 2.0 | GV.OC-03 — Mission Objectives and Stakeholder Expectations | Scope should reflect how the system is actually used and expected by users. |
| Recommendation — Align the chatbot scope decision with actual stakeholder expectations and product purpose. | ||
Practitioner Guidance
What to verify: Confirm whether the system is designed to remember users, mirror emotion, sustain ongoing interaction, or present a relational persona. If those behaviors are present, scope should be documented at the companion-function level, not only at the parent-product level.
Decision rule: If a reasonable user could experience the system as a companion, classify it for scope as a companion chatbot even when the vendor labels it as support, entertainment, wellness, or general AI.
Practitioner takeaway: The safest scope rule is to classify by user-facing function and interaction design, because legal and operational obligations follow the lived product behavior, not the product’s internal taxonomy.
Related resources from NHI Mgmt Group
- How should security teams run SOX access reviews across multiple in-scope systems?
- What breaks when an AI assistant is connected to enterprise email and cloud systems without tight scope limits?
- How should teams assess IAM maturity when NHIs and AI systems are in scope?
- What breaks when an AI tool is connected to codebases and ticketing systems without tight scope control?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org