# IAM split — n8n caller vs harness execution role

Two principals. Do not collapse them into one long-lived key.

Canonical statements: [AgentCore harness security](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html). The node README maps features to those sections and **does not** ship a broad permission policy so it cannot drift from AWS.

## 1. Caller (goes in the n8n credential)

The IAM user or role whose access keys (or STS session) n8n uses.

- Grant **only** the [Required IAM permissions for callers](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html#harness-iam-permissions) table.
- Scope to your harness ARN where the table allows (`ListHarnesses` requires `*`).
- Prefer **temporary credentials** (IAM Identity Center or STS) with a session token on the n8n **Amazon Bedrock AgentCore API** credential. Do not commit keys.
- For inbound-OAuth harnesses, SigV4 still covers control-plane calls; invoke uses a **bring-your-own JWT** on the same credential. SigV4 callers do **not** get per-user Identity token-vault / on-behalf-of scoping — that requires inbound JWT ([harness security note](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html)).

## 2. Execution role (harness assumes this at runtime)

This is the role ARN stored on the n8n credential as **Execution Role ARN**.

- Start from the [sample execution role policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html#_sample_execution_role_policy).
- Trust: AgentCore must be allowed to assume the role (see `docs/iam-trust-policy.json` in [`aws/n8n-nodes-agentcore`](https://github.com/aws/n8n-nodes-agentcore)).
- Add **optional** blocks only for features you enable: Memory, Gateway, Browser, Code Interpreter, private ECR, VPC managed-image pull, S3 skills, API-key / OAuth2 credential providers.

## What not to do

- Do **not** paste `AmazonBedrockFullAccess` or `bedrock-agentcore:*` on either principal “to make the node work.”
- Do **not** reuse the n8n orchestration role (IRSA / SES / S3 workflow exports) as the harness execution role.
- Do **not** put the execution role’s long-lived keys in n8n — n8n should never assume that role locally; AgentCore assumes it.

## n8n host credentials (separate again)

If n8n runs on EKS, IRSA for the **n8n workload** (Secrets Manager for `N8N_ENCRYPTION_KEY`, optional S3 workflow export) is a third identity. See [n8n on EKS](https://www.factualminds.com/blog/how-to-host-n8n-on-aws-eks-production-guide/).
