An attack vector is the specific pathway or method used to exploit part of the attack surface. It can be a stolen credential, a misconfigured service, a phishing message, or a vulnerable integration. In identity-heavy environments, vectors often succeed because the access looks legitimate once the attacker obtains valid authorization.
Expanded Definition
An attack vector is the route an adversary uses to reach a weakness, but in NHI-heavy environments it is best understood as the mechanism that turns exposure into execution. For service accounts, API keys, agent tool permissions, and secrets, the vector often looks ordinary because the attacker is borrowing valid identity and access rather than forcing a noisy exploit. That is why the term sits at the intersection of IAM, application security, and threat modelling. Definitions vary across vendors when teams discuss whether the vector is the initial entry point, the delivery method, or the specific credential path, so practitioners should be explicit about the scope they mean. In practice, the most useful framing is the one used in the MITRE ATLAS adversarial AI threat matrix and in operational guidance from CISA cyber threat advisories: focus on how the attacker moves from exposure to access, then to action.
The most common misapplication is treating an attack vector as the same thing as the attack surface, which occurs when teams describe every exposed asset instead of the specific path an attacker actually used.
Examples and Use Cases
Implementing attack-vector analysis rigorously often introduces investigative overhead, requiring organisations to weigh faster triage against the cost of tracing each path back to a root cause.
- A leaked cloud access key becomes an attack vector when an attacker uses it to call management APIs within minutes, a pattern highlighted in LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- A phishing email is only the vector if it leads to credential capture or token theft, not merely because it delivered a malicious link.
- A misconfigured integration can become the vector for lateral movement when an agent or CI/CD runner inherits excessive permissions from a service account.
- An exposed database connection string in code is an attack vector when it enables direct access to backend systems before rotation or revocation can occur.
- In agentic workflows, a malicious prompt or tool invocation path can function as the vector once it drives a privileged action through an autonomous software entity.
For NHI context, the Ultimate Guide to NHIs — Key Challenges and Risks shows how exposed secrets, over-privileged accounts, and weak rotation combine into repeatable paths. The MITRE ATLAS adversarial AI threat matrix is also useful when the vector involves model tooling, prompt injection, or agent execution authority.
Why It Matters in NHI Security
Attack vectors matter because NHI compromise rarely starts with a dramatic breach of perimeter controls. It usually starts with a valid credential, a stale token, a misrouted permission, or a third-party integration that should never have had standing access. NHI Mgmt Group research in Ultimate Guide to NHIs — Why NHI Security Matters Now shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a strong signal that the decisive factor is often the access path, not the payload. That is why attack-vector analysis should inform secret hygiene, PAM, RBAC, JIT, and ZSP decisions, not sit only in incident reports. The same logic appears in The 52 NHI breaches Report, where the recurring pattern is not novelty but reuse: exposed identity, rapid abuse, then operational impact. Organisations typically encounter the consequences only after tokens are used in production or agent actions are replayed, at which point the attack vector becomes operationally unavoidable to address.
When defenders understand the vector, they can block the path rather than merely clean up the aftermath. That is the difference between containing a secret leak and repeatedly relearning the same compromise.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers insecure secret handling and exposed NHI paths used as vectors. |
| OWASP Agentic AI Top 10 | A2 | Addresses prompt and tool abuse as attack paths for autonomous agents. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust limits how an initial access path can expand into broader compromise. |
Find and rotate exposed secrets, then remove standing paths that let them be reused.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org