TL;DR: Teleport says regulators and auditors now expect immutable proof of every privileged action across SSH, Kubernetes, databases and RDP, but fragmented logs, shared credentials and disconnected audit trails still leave trading firms unable to attribute actions to a specific identity. Audit readiness fails when evidence is reconstructed after the fact instead of being produced natively at session time.
At a glance
What this is: This is a trading infrastructure audit-readiness analysis showing that SSH, Kubernetes, database and RDP logs often fail at identity attribution even when they capture activity.
Why it matters: It matters because IAM, PAM and infrastructure teams need audit evidence that ties privileged actions to a specific identity across heterogeneous systems, not a manual reconstruction exercise.
👉 Read Teleport's analysis of identity attribution gaps in trading infrastructure audit trails
Context
Trading infrastructure audit readiness breaks when privileged actions can be logged but not attributed. In this article, the primary governance gap is identity attribution across SSH, Kubernetes, databases and RDP, where the evidence exists in pieces but not as a coherent chain.
For high-frequency trading, quantitative finance and similar regulated environments, that gap matters because auditors want immutable proof tied to a person or machine identity. A logging stack that records commands, sessions or API events without a shared identity context still leaves compliance teams rebuilding the story by hand.
The problem is not limited to one protocol. It is a cross-surface audit design issue: identity and session evidence are separated at the exact point where regulators expect them to converge.
Key questions
A: Shared credentials collapse multiple users into one visible account, so the log can confirm access without proving which engineer or operator performed the action. That breaks identity attribution, weakens evidence for auditors and makes incident reconstruction dependent on manual correlation across unrelated systems.
Q: Why do regulators care so much about identity attribution in trading infrastructure?
A: Because privileged actions in regulated environments must be provably tied to a specific identity, not just to a system account or session record. Without that chain, compliance teams cannot demonstrate who accessed sensitive systems, who changed data or whether access was properly authorised.
Q: How can security teams tell whether audit logging is actually fit for purpose?
A: A useful test is whether an auditor can start with one privileged action and trace it back to one authenticated identity without reconstructing the story from multiple tools. If the answer requires manual log stitching, the audit control is still incomplete.
Q: What should teams do when SSH, Kubernetes, database and RDP logs do not line up?
A: They should treat the gap as an identity governance problem, not a logging problem. The immediate aim is to preserve a single identity chain across access, session and command evidence so the audit trail survives review without unsupported assumptions.
Technical breakdown
Why SSH keys and bastion logs fail attribution
SSH on bare-metal systems often records that a key was accepted, not who used it. Shared keys, standing privileges and non-expiring credentials make the audit trail weak because the log proves access only at the credential level. Bastion hosts and local server logs can preserve session metadata, but without identity binding they do not answer the core audit question: who performed the action. In regulated trading environments, that gap is amplified by legacy systems and geographically distributed server estates that sit outside cloud-native monitoring paths.
Practical implication: Treat SSH audit evidence as incomplete unless the session is tied to an individual identity at connection time.
How Kubernetes audit events lose the initiating identity
Kubernetes audit logs can show a pod exec, a namespace and a service account, but they often do not identify the human or machine that initiated the session. Shared kubeconfigs and centrally managed credentials collapse multiple users into one visible identity, which is convenient for access but poor for forensics and compliance. The result is a log that describes what happened inside the cluster while obscuring who triggered it upstream. To an auditor, that means the Kubernetes API trail is necessary but not sufficient for identity attribution.
Practical implication: Correlate Kubernetes events with upstream identity proof at issuance time, not after an audit request arrives.
Why database and RDP logs are not enough on their own
Database logs typically record the database account, not the upstream human identity, especially when teams use shared accounts or separate database credentials. RDP and Windows event logs have the same limitation: they confirm a logon and session boundary but not the business action performed inside the session. That creates a blind spot for regulated data, trading risk settings and operational changes. The technical issue is not logging volume. It is that the session telemetry is detached from the identity chain that auditors need to see.
Practical implication: Design database and RDP controls so the session record preserves the authenticated identity, not just the access account.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity attribution, not log collection, is the real audit control. Trading firms often already have logs, but they do not have a consistent identity chain across protocols. That breaks the evidentiary model auditors depend on because the same privileged act can be visible in three systems and attributable in none of them. The practitioner implication is that audit readiness has to be engineered as a cross-protocol identity problem, not treated as a reporting cleanup task.
Shared credentials create an audit fiction that survives until an assessor asks for proof. A shared SSH key, kubeconfig, database account or RDP service login may be operationally convenient, but it destroys the ability to tie a privileged act to a person or machine. In governance terms, the issue is not merely overuse of access. It is the loss of evidentiary accountability when multiple actors collapse into one logged identity. Practitioners should treat any shared credential in a regulated trading path as an attribution defect, not just a privilege concern.
Short-lived, session-bound identity is the right model for regulated infrastructure evidence. The article points toward a control pattern where the identity is asserted at the moment of access and preserved through the full session lifecycle. That is the practical bridge between IAM, PAM and audit logging: authenticate once, bind the session, and carry the attribution through commands, queries and exports. For trading environments, this is the difference between being able to answer an auditor and having to reconstruct the answer.
Cross-protocol audit evidence needs a single operational source of truth. When SSH, Kubernetes, databases and RDP each produce different log formats and retention assumptions, evidence correlation becomes a manual investigation. That scales poorly and weakens compliance posture even when no incident has occurred. The stronger operating model is one where privileged sessions are normalized into a common audit record before they reach the SIEM or the audit review queue.
Unified audit trail: fragmented protocol logs are not enough when regulators want identity-attributed evidence. The article shows that trading infrastructure needs audit evidence generated at the time of connection, not assembled later from IdP logs, bastions and cloud trails. That shifts the governance burden from review to issuance and makes identity attribution the primary control objective for regulated operations.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Unified audit evidence has to be produced, not reconstructed. Trading firms that leave identity attribution to post-hoc correlation are accepting a governance model that auditors can reject at any time. The stronger pattern is to bind session, privilege and identity at the moment access begins, then carry that record into compliance and security workflows.
Identity attribution is the control boundary that matters across mixed infrastructure. SSH, Kubernetes, databases and RDP each expose different logging mechanics, but the audit question is the same: who did what, under which authenticated identity, and with what privilege? Programmes that cannot answer that cleanly should re-evaluate their privileged access and session recording model.
Audit-ready infrastructure depends on attribution-first design. For regulated trading environments, that means identity proof must travel with the session instead of being inferred later from separate logs. If the evidence cannot survive an auditor’s follow-up question, the underlying governance model is still too fragmented.
For practitioners
- Bind privileged sessions to a unique identity at connection time Ensure SSH, Kubernetes, database and RDP sessions are issued with a session-specific identity record so downstream actions are attributable without log stitching.
- Eliminate shared access accounts from regulated paths Remove shared kubeconfigs, shared database accounts and shared RDP logins from trading workflows where auditors need action-level accountability.
- Normalize protocol logs into one audit trail Route session metadata, commands and query activity into a single structured record that preserves identity, privileges and timestamps across protocols.
- Preserve command-level evidence for privileged sessions Capture the command, query or session action itself so reviewers can see what happened inside the access window instead of only knowing that a login occurred.
Key takeaways
- The core issue in trading infrastructure is not whether activity is logged, but whether each privileged action can be tied to a specific identity across protocols.
- SSH keys, shared kubeconfigs, database accounts and RDP service logins all weaken attribution when multiple operators use the same credential path.
- The most defensible control model binds identity at session start and preserves that chain through commands, queries and exports.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared keys and shared accounts create excess, untraceable access in regulated infrastructure. |
| NHI-01 — Improper Offboarding | Long-lived SSH keys and shared credentials persist beyond useful accountability windows. | |
| NHI-10 — Human Use of NHI | Human operators using shared machine credentials obscures who actually performed privileged actions. | |
| Recommendation — Replace shared access paths with individually attributable NHI sessions and remove standing privilege from regulated workflows. Revoke and replace dormant credentials so audit evidence does not rely on stale access paths. Prevent human operators from sharing machine credentials and bind each session to one accountable identity. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about proving and constraining who had access to privileged systems. |
| Recommendation — Align entitlements with individually traceable access and preserve evidence of authorization for every privileged session. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys, kubeconfigs and database credentials all require lifecycle control and traceability. |
| Recommendation — Manage authenticators so each privileged session can be traced to a unique, revocable credential. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Shared credentials and weak attribution are the conditions attackers abuse after initial compromise. |
| Recommendation — Map weak attribution paths to credential access and lateral movement risk in your detection and response planning. | ||
Key terms
- Identity Attribution: Identity attribution is the ability to determine which entity performed an action and under what authority. For AI agents, it requires separate identities, structured logs, and traceable decision records so investigations can distinguish human intent from autonomous execution.
- Unified audit trail: A single evidence stream that links identity proofing, authentication, consent, and executed actions across human and non-human actors. It matters because split logs prevent teams from reconstructing what the agent was allowed to do and what it actually did.
- Session Bound Identity: Session bound identity means the access event is tied to the identity at the moment the session starts and remains linked through the session’s commands or queries. For regulated infrastructure, this is the difference between a log entry that proves access and an audit record that proves accountability.
- Audit Evidence: Audit evidence is the record set used to prove that access was authorised, limited, and revoked according to policy. For modern identity programmes, evidence must come from runtime logs, approval events, and lifecycle records rather than from manual spreadsheets assembled after the fact.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Examples of SSH, Kubernetes, database and RDP log formats and what each one does and does not prove
- Structured audit-log design details for tying session activity back to a single identity record
- How short-lived session certificates preserve attribution across privileged access workflows
- The Exness case study showing identity attribution across hundreds of clusters and systems
👉 Teleport's full post shows how to unify SSH, Kubernetes, database and RDP evidence for audits
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org