AWS Security Token Service is the service that issues temporary credentials for AWS access. These tokens expire after a short period and can be scoped to specific permissions, which reduces the value of stolen credentials. It is a core control for replacing static secrets with ephemeral access.
Expanded Definition
AWS Security Token Service is best understood as an ephemeral access broker for AWS, not as a general authentication system. It mints short-lived session credentials that can carry narrower permissions than long-lived keys, which makes it central to reducing standing secret exposure across workloads, automation, and federated access. In NHI operations, the practical distinction is between durable secrets that can be reused indefinitely and time-bound credentials that expire even if they are copied. That distinction matters because it changes both attacker value and defender response time.
Definitions vary across vendors when teams discuss whether STS should be treated as an identity layer, a credential issuer, or a session-management control. For AWS governance, the safest interpretation is to treat it as an enforcement point for temporary, scoped access that should sit inside broader policies for least privilege, token lifecycle, and revocation readiness. AWS documentation on AWS Security Token Service describes the service model and session credential behaviour.
The most common misapplication is treating STS sessions as automatically safe, which occurs when teams grant broad role permissions and then assume short expiry alone compensates for over-privilege.
Examples and Use Cases
Implementing AWS Security Token Service rigorously often introduces operational overhead, requiring organisations to weigh reduced secret persistence against more complex role design, session handling, and automation testing.
- CI/CD pipelines use STS to assume deployment roles instead of storing static AWS keys in build variables or repository settings.
- Cross-account access is issued as temporary sessions so a workload can reach only the specific AWS resources required for a bounded task.
- Federated workforce access can rely on STS so engineers never handle long-lived access keys for routine console or API activity.
- Incident response teams can shorten session duration during containment to reduce the usefulness of any stolen credentials.
- Secret-sprawl reviews can compare STS-based access against hardcoded keys to identify where ephemeral access has not yet replaced durable credentials, as discussed in the Guide to the Secret Sprawl Challenge and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research from Entro Security.
Cloud security guidance from NIST Cybersecurity Framework 2.0 is often used alongside STS deployments to structure access governance and monitoring.
Why It Matters in NHI Security
AWS Security Token Service matters because it changes the blast radius of credential exposure. Short-lived credentials are still credentials, but they reduce the window in which an attacker can reuse them and they are far less valuable than static secrets that remain valid for months. That is especially important in NHI environments where agents, workloads, and automation chains frequently exchange credentials faster than human reviewers can inspect them. When STS is used well, it supports Zero Standing Privilege patterns and makes rotation less dependent on manual cleanup.
NHIMG research shows why this discipline is urgent: when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and in some cases within 9 minutes. That speed means token-based controls are not just a design preference, they are a response to attacker dwell-time reality. The same pressure appears in breach patterns where tokens, keys, and session material become the path to lateral movement rather than the final objective.
Organisations typically encounter the operational importance of STS only after an exposed key or mis-scoped role has already been used, at which point temporary credential governance becomes unavoidable to contain the incident.
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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Temp creds and secret sprawl are central to NHI credential misuse guidance. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access provisioning covers temporary credential issuance and role trust. |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero trust relies on short-lived, continuously evaluated access tokens. |
| NIST SP 800-63 | AAL2 | Assurance concepts inform how strongly temporary AWS access should be protected. |
| OWASP Agentic AI Top 10 | A3 | Agentic systems often abuse over-permissive cloud tokens and session credentials. |
Constrain agent access through least-privilege, short-lived credentials and explicit session boundaries.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
