A recurring and concerning pattern I have observed in recent architectural reviews, particularly within orchestration frameworks for autonomous agents, is the casual inheritance of IAM roles from their host compute environment. This practice, while operationally convenient, fundamentally violates the principle of least privilege and creates a significant, persistent attack vector. The agent's effective permissions become an opaque superset of its intended capabilities, dictated by the often broadly-scoped role attached to the underlying virtual machine, container host, or orchestrator node.

The core issue is a misalignment between the lifecycle and purpose of the *infrastructure* role and the *workload* role. A host role may legitimately require permissions for disk attachment, network interface management, or logging agent installation—concerns irrelevant to the application logic. When an agent inherits this role, it gains these permissions unnecessarily. More critically, if the agent is compromised through a dependency exploit (a non-trivial risk, as we consistently discuss in the context of software bills of materials), the attacker's lateral movement capabilities are dramatically expanded.

Consider a typical deployment pattern for a data-processing agent on a cloud compute instance:
```json
// Host Instance Role (e.g., attached via instance profile)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"logs:CreateLogStream",
"logs:PutLogEvents",
"ec2:DescribeInstances",
"ssm:GetParameters"
],
"Resource": "*"
}
]
}
```
The agent's task may only require read access to a specific S3 bucket prefix, yet it inherits the ability to write to any S3 bucket, describe all EC2 instances, and retrieve arbitrary SSM parameters. The `Resource: "*"` scope exacerbates the risk. This is not a hypothetical; it is the default in numerous quick-start guides and terraform modules.

The mitigation requires a deliberate architectural shift:
* **Workload Identity Federation:** Utilize mechanisms like AWS IAM Roles for Service Accounts (IRSA) with EKS, Azure Pod Identities, or GCP Workload Identity. These allow the agent pod or function to authenticate directly to a cloud IAM role scoped exclusively to its workload.
* **Explicit, Narrow Role Assumption:** If inheritance is unavoidable, design the host role with the singular permission to assume a more specific, workload-defined role. The agent must then explicitly call `sts:AssumeRole`, and the host role itself should have no other data-plane permissions.
* **Runtime Credential Configuration:** Agents should be configured to load credentials from a well-defined, scoped source (e.g., a specific OIDC provider or a vault path) at runtime, rather than inheriting the instance profile metadata service context.

I am particularly interested in how this intersects with SLSA build provenance and Sigstore signing. If an agent with inherited, excessive permissions is tasked with signing artifacts or attestations, the compromise of that agent compromises the integrity of the entire signing system. The build pipeline's IAM role is another common culprit here. Have others conducted formal audits of the IAM roles assumed by their CI/CD runners versus the roles used for signing and publishing? The separation between "can build" and "can sign" must be enforced at the IAM layer, not just in pipeline logic.