Perplexity security depends on tier controls and interaction-layer governance

At a glance

What this is: This is an analysis of how Perplexity security splits between provider controls and enterprise governance, with Comet adding agentic browsing risk and visibility gaps.

Why it matters: It matters because IAM, PAM, and AI governance teams need to control who can use which tier, what data can enter prompts, and how authenticated sessions are governed.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read WitnessAI's analysis of Perplexity security and Comet risk

Context

Perplexity security is a governance problem before it is a product problem. The key issue is not whether the provider offers enterprise controls, but whether organisations can actually enforce tier choice, data handling, and session oversight when employees move between work and personal accounts. That boundary matters because the same prompt can fall under very different contractual and audit conditions depending on how the user logs in.

Comet introduces a second layer of risk because it can act inside authenticated sessions. Once an AI browser can read pages, follow instructions, and trigger actions, the control question shifts from content moderation to runtime authorisation. Traditional tools built around network traffic, files, and static data often miss the interaction context that now determines exposure.

This pattern is typical of the broader Shadow AI problem: policy can look sound on paper while actual usage happens somewhere else. For identity and access teams, the real challenge is not simply approving AI tools, but governing who gets to use them, under which account, and with what delegated reach.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do agentic AI systems create more security risk than standard chatbots?

A: Agentic systems can turn model output into action, which means a bad instruction can affect code flow, tool use, and downstream state. Standard chatbots usually stop at text generation. Agentic AI adds execution authority, so compromise can lead to disclosure, unauthorized changes, or misuse of credentials.

Q: What breaks when AI governance does not include interaction-level visibility?

A: Teams lose the ability to prove which account was used, what was prompted, and what action followed. Without that context, policy enforcement becomes retrospective guesswork instead of runtime control. The result is a blind spot that hides personal-account use, prompt injection, and unsanctioned data movement.

Q: Who is accountable when sensitive data is retained in a third-party AI tool?

A: Accountability sits with the organisation that allowed the data into the tool, even if the provider stores or processes it. Teams need clear ownership for prompt retention, deletion requests, and vendor data processing terms. If the provider cannot prove erasure or lineage, the organisation still carries the compliance and privacy risk.

Technical breakdown

Shared responsibility in enterprise AI usage

Shared responsibility in AI tools means the provider secures its platform-side controls while the enterprise governs user behaviour, account assignment, and acceptable data use. In practice, that includes identity management, auditability, retention terms, and policy enforcement across approved and unapproved tiers. When consumers can switch between enterprise and personal accounts, the security model becomes conditional on login context, not just the application itself. That is why governance has to follow the user, not just the vendor contract.

Practical implication: tie AI access to identity policy, tier approval, and usage monitoring rather than assuming provider controls cover the full workflow.

Agentic browser risk and prompt injection

Agentic browsers change the threat model because they can interpret content and take actions inside already-authenticated sessions. Prompt injection is the central failure mode: malicious instructions embedded in a page can be treated as valid task input by the AI system. Once that happens, the browser may read messages, copy one-time codes, or interact with connected services using the user’s privileges. This is not the same as a conventional browser exploit. It is a trust-boundary problem where the model is persuaded to act on attacker-controlled instructions.

Practical implication: treat agentic browsing as privileged automation and add runtime controls for prompt injection, action scoping, and session logging.

Why interaction-layer visibility matters for AI governance

Interaction-layer visibility means seeing the prompt, the account type, the response, and the resulting action in one control plane. That is different from monitoring only traffic or files, because AI risk often sits in the conversation itself. Security teams need to know whether a prompt came from an enterprise account, a personal account, or an autonomous session, and whether the resulting action touched sensitive data or external systems. Without that context, policy enforcement becomes guesswork. The governance gap is the lack of runtime evidence at the exact point of AI use.

Practical implication: instrument AI activity where prompts and actions occur so policy decisions can be enforced and audited in real time.

Threat narrative

Attacker objective: The attacker aims to turn a legitimate AI-assisted session into a channel for credential theft, sensitive data disclosure, or unauthorized actions.

1. Entry occurs when an employee uses an AI tool through a personal account or an agentic browser inside an authenticated web session.
2. Escalation follows when injected instructions inside web content steer the AI to read messages, retrieve codes, or act with the user’s privileges.
3. Impact is unauthorized disclosure or misuse of sensitive information through a trusted session that security tools did not observe at the interaction layer.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Interaction-layer governance is now the decisive control plane for enterprise AI. The article shows that provider-side assurances are insufficient once users can move between enterprise and personal accounts. Security leaders need policy enforcement where prompts, account type, and session actions meet, because that is where actual exposure occurs. This is a NIST CSF and NIST SP 800-53 concern as much as an AI governance one, since auditability and access control have to extend into the interaction layer. The practitioner conclusion is clear: identity policy must govern AI usage at runtime, not only at procurement.

Agentic browsing creates a privileged automation problem, not just a prompt safety problem. Comet’s ability to act inside authenticated sessions means prompt injection can become an access issue, not merely a content issue. That shifts the relevant control question from whether the model is safe to whether the delegated action is bounded. In NHIMG terms, this is where AI-to-identity delegation needs explicit governance, because a browser that can follow instructions is functionally carrying user privilege. Practitioners should treat delegated session action as a governed privilege.

Shadow AI visibility gaps are now part of identity governance debt. When employees can reach consumer tiers without enterprise oversight, the organisation loses contractual protection, audit trails, and data handling certainty. That is a governance debt problem because the gap accumulates silently across users and workflows until an incident forces discovery. The named concept here is interaction-layer blind spot, and it describes the failure to see which account, prompt, and action combination actually governed the event. The practitioner takeaway is to build discovery that follows usage, not just approved inventory.

Contractual controls are necessary but not sufficient for AI data protection. Enterprise retention terms, admin settings, and audit trails matter, but they do not stop users from pasting corporate data into personal sessions. The governance assumption that policy choice equals policy enforcement fails here. This is why AI governance has to join identity policy, behavioural monitoring, and runtime controls. For practitioners, the lesson is to validate both the written contract and the observed path of data through the tool.

AI governance programmes should align with existing security frameworks, not invent parallel ones. NIST CSF, NIST SP 800-53, and OWASP guidance already provide enough structure to map access control, audit, and prompt-injection risk. The mistake is to treat AI as exempt from standard control design. The article reinforces that AI systems still rely on identity, authorization, and logging decisions that security teams already know how to govern. The practitioner conclusion is to extend current controls into AI workflows rather than building a separate governance island.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% saying visibility is only partial, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to the same research.
• The visibility gap is a governance problem, so readers should next review Ultimate Guide to NHIs , Why NHI Security Matters Now for the lifecycle controls that close it.

What this signals

Interaction-layer blind spots will become a board-level AI governance issue. Once employees can move between enterprise and personal access paths, security teams need evidence that policy actually followed the session. The practical signal is not more AI usage reporting, but whether access, prompts, and actions are being tied back to identity and retained for review.

AI governance debt accumulates when runtime controls lag behind adoption. The longer teams wait to instrument prompts, responses, and delegated actions, the more difficult it becomes to prove compliance or contain misuse. That is especially true where agentic browsing can operate inside authenticated sessions and bypass the assumptions of traditional monitoring.

Identity teams should expect AI usage controls to merge with existing access governance workflows. That means approved tiers, session logging, and policy enforcement will increasingly sit beside IAM, PAM, and data protection controls rather than in a separate AI-only programme. Organisations that align those controls early will have a clearer path to safe adoption.

For practitioners

• Separate enterprise and personal AI access paths Require identity-based tier assignment for approved AI tools and block corporate data from personal accounts through policy, monitoring, and user education. Verify that the approved tier is the only one permitted for sensitive workflows.
• Instrument AI activity at the interaction layer Capture prompts, responses, account type, and downstream actions in a single audit trail so reviewers can reconstruct what happened inside each session. Prioritise visibility for users who can switch between enterprise and consumer access.
• Treat agentic browsing as privileged automation Limit what Comet-style sessions can reach, require scoped permissions, and log actions performed inside authenticated tabs or connected services. If the session can act on behalf of the user, it needs the same containment thinking as other elevated workflows.
• Add runtime protection against prompt injection Inspect both incoming content and outgoing responses for malicious instructions, data exfiltration attempts, and unsafe delegation. Use controls that can warn, block, or route risky interactions before they trigger actions in connected systems.
• Review contract terms and retention settings before rollout Confirm zero-retention, training restrictions, audit access, and deletion commitments for the exact plan in use. Do not assume enterprise protections apply uniformly across all tiers, sessions, or connected services.

Key takeaways

• Perplexity security is fundamentally a shared-responsibility issue, because enterprise controls do not automatically govern personal-account use or agentic browsing.
• The most important exposure is at the interaction layer, where prompts, identity context, and delegated actions determine whether policy is actually enforced.
• IAM and AI governance teams should treat Comet-style behaviour as privileged automation and require identity-based tier control, runtime logging, and prompt-injection protection.

Key terms

• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Agentic Browser: An agentic browser is a web browser with an embedded AI assistant that can interpret page content and take actions on the user’s behalf. It combines browsing, reasoning, and execution in one interface, which creates new governance requirements for identity, data handling, and approval boundaries.
• Interaction-Layer Visibility: The ability to see prompts, responses, account context, and resulting actions as one governed event. This is the control layer where AI usage becomes auditable, because traffic monitoring alone cannot explain whether a prompt came from an approved account or how the session behaved.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

What's in the full article

WitnessAI's full article covers the operational detail this post intentionally leaves for the source:

• Plan-by-plan differences in enterprise controls, retention terms, and admin settings for Perplexity use.
• Detailed examples of Comet prompt-injection behaviour and how those tests translated into session-level risk.
• WitnessAI's network-level discovery approach for finding AI activity routed through the platform without endpoint tooling.
• Runtime policy actions and guardrail behaviour for blocking or routing risky AI interactions.

👉 The full WitnessAI article covers enterprise controls, Comet attack behaviour, and runtime guardrails in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader AI and access governance work their programmes already own.