Subscribe to the Non-Human & AI Identity Journal

Bidirectional override character

A bidirectional override character changes the display order of surrounding text so code can appear to mean one thing while executing another. Attackers use these characters to hide logic, disguise payloads, and make malicious code harder to spot in diffs, comments, and generated files.

Expanded Definition

A bidirectional override character is a Unicode control that changes how text is rendered so the visible order can differ from the underlying code order. In security reviews, that makes it possible to conceal logic, misread filenames, and disguise malicious content inside comments, identifiers, or generated artefacts. The issue is not the character alone but the mismatch it creates between what a reviewer sees and what the parser or interpreter processes. This is why the term sits at the intersection of source-code integrity, supply chain review, and human review error. Standards do not always name the character explicitly, but secure development guidance and file-handling controls assume defenders must preserve trustworthy representation of code and text, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls. Definitions vary across vendors and tooling ecosystems, especially where editors, diff viewers, and scanners render bidirectional text differently. The most common misapplication is assuming a clean-looking diff is safe when the file contains hidden directionality controls that only become obvious in a different viewer or terminal.

Examples and Use Cases

Implementing detection and remediation rigorously often introduces review friction, requiring organisations to weigh cleaner code presentation against stricter scanning and normalization controls.

  • A malicious pull request hides an injected command by reversing the visible order of part of a shell line, making the review appear harmless until execution.
  • A repository contains a filename that looks like a benign script but is rendered differently in some interfaces, helping a payload blend into build or deployment paths.
  • A code comment or documentation block includes directionality control characters that confuse reviewers and conceal a risky configuration change.
  • A CI pipeline flags hidden Unicode controls during pre-commit checks, preventing the issue before it reaches JetBrains GitHub plugin token exposure style review workflows where exposed secrets or deceptive code can compound each other.
  • Security teams compare suspicious files against guidance in Ultimate Guide to NHIs and 2025 Outlook and Predictions when hidden text appears alongside secrets, API keys, or service account material in code.

Why It Matters for Security Teams

Bidirectional override characters matter because they undermine trust in the artifact that developers, security reviewers, and automated scanners think they are approving. In practice, they can turn a routine code review into a deception problem, especially when files carry secrets, deployment instructions, or agent tool configurations that look benign under normal rendering. For NHI and agentic AI governance, the concern is broader than source code: hidden text can obscure API keys, service account settings, MCP-related configuration, and automated action scripts that grant execution authority. That makes text normalization and safe rendering part of identity and secrets hygiene, not just a developer convenience. NHIMG research shows 30.9% of organisations store long-term credentials directly in code, which increases the value of hiding malicious or sensitive content inside otherwise ordinary files. Controls need to cover editor behaviour, diff rendering, repository scanning, and secure handling of text encodings. Organisations typically encounter the impact only after a poisoned commit, leaked secret, or misleading review slips through, at which point bidirectional override character handling becomes operationally unavoidable to address.

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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.DS Text integrity and secure handling align with protecting code and data from manipulation.
NIST SP 800-53 Rev 5 SI-7 Integrity checks help detect altered or deceptive content in files and code paths.
OWASP Non-Human Identity Top 10 NHI-08 Hidden text can conceal exposed secrets and weaken non-human identity governance.
NIST AI RMF AI risk management covers deceptive inputs and integrity issues that affect model pipelines.
NIST AI 600-1 GenAI profile guidance addresses content integrity and safer handling of model inputs.

Validate text inputs and artifacts for hidden controls before they reach AI or agent workflows.