Who is accountable when an AI relay package exposes prompts or credentials?

Accountability sits with the team that approved the tooling, the environment owner that allowed sensitive secrets to be present, and the operator that controlled the relay if it was outside the intended trust boundary. Governance frameworks should assign responsibility before the tool is installed, not after data is exposed.

Why This Matters for Security Teams

An AI relay package is not just a transport layer. If it can expose prompts, tokens, API keys, or embedded secrets, it becomes a governance boundary that can fail fast and fail wide. Accountability matters because the blast radius is usually shaped before the incident: tool approval, environment design, secret placement, and operator access all determine whether the relay can leak what it handles. The control question is less “who saw the output” and more “who accepted the risk of the relay existing in that form.”

This is why NHI governance cannot be treated as a post-incident blame exercise. Guidance from the OWASP Non-Human Identity Top 10 and NIST control families both point toward pre-authorised ownership, least privilege, and secret minimisation before a workload is deployed. NHIMG’s research shows that organisations still struggle with secret handling at a basic level, with Guide to the Secret Sprawl Challenge highlighting how easily sensitive material spreads across tools and environments. In practice, many security teams encounter accountability gaps only after a relay has already exposed credentials, rather than through intentional design review.

How It Works in Practice

Accountability should be assigned across three layers: the team that approved the tool, the environment owner that allowed sensitive data to exist in the relay path, and the operator that controlled the relay when it crossed the intended trust boundary. For AI and agentic systems, that ownership model is consistent with emerging guidance from Anthropic’s AI-orchestrated cyber espionage report, which reinforces that autonomous workflows can chain actions quickly once they have access.

Practically, teams should define the relay as a governed workload with explicit identity, policy, and secret-handling rules:

• Give the relay a workload identity, not a shared human account.
• Issue just-in-time credentials with short time-to-live values, and revoke them when the task ends.
• Store prompts, logs, and intermediate artifacts as sensitive data by default, because they often contain credentials or retrieval context.
• Apply request-time policy checks rather than assuming a static role assignment is enough.
• Separate approval authority from operational custody so the same person is not both authorising and silently inheriting risk.

The security value is highest when secrets are never present in long-lived form. NHIMG’s Ultimate Guide to NHIs – Static vs Dynamic Secrets explains why dynamic credentials reduce exposure windows, while NIST’s SP 800-53 Rev. 5 Security and Privacy Controls supports disciplined access, auditability, and system integrity. These controls tend to break down when relay packages are embedded in CI/CD pipelines with shared logs, reusable service tokens, and no clear environment owner for the downstream secret stores.

Common Variations and Edge Cases

Tighter relay controls often increase delivery overhead, requiring organisations to balance faster automation against stricter segregation and approval steps. That tradeoff becomes sharper when relay packages sit inside agentic workflows, because the package may not be malicious itself but may still expose sensitive context if an upstream model, plugin, or connector behaves unexpectedly.

There is no universal standard for exactly how much responsibility the platform team should retain versus the application team, so current guidance suggests using a named risk owner and a documented trust boundary. In SaaS-to-SaaS relays, the vendor may control the runtime, but the customer still owns what gets placed into the relay. In internal environments, the operator may run the relay, but the approving team still owns the decision to permit prompts or secrets to traverse it.

For identity and access design, the practical lesson aligns with the 52 NHI Breaches Analysis and the 2024 Non-Human Identity Security Report: exposure is rarely caused by one failure alone. It usually combines weak secret discipline, overbroad access, and unclear ownership. Security teams should treat relay-package approval as a formal accountability decision, not a tooling preference.

Related resources from NHI Mgmt Group

• When do AI agent credentials create more risk than they reduce?
• How should security teams govern machine identity credentials in agentic AI environments?
• Why do AI agents create more risk when they reuse existing credentials?
• How should organizations manage credentials for AI agents?