## TL;DR

The ERP allowlists specific source addresses and the agent's egress is not among them. Route the agent through stable egress addresses (a NAT gateway or egress proxy with fixed addresses), add those addresses to the ERP allowlist, and verify connectivity.

## Error

```text
agent failed to access the erp: ip allowlist blocked its egress
```

## Steps

1. Confirm the block: check the ERP's access logs for denied connections from the agent. Expected: the deny entries name the agent's egress address.
2. Give the agent stable egress: a NAT gateway or egress proxy with fixed public addresses. Expected: the agent's outbound traffic comes from known addresses.
3. Add those addresses to the ERP's IP allowlist. Expected: the allowlist includes the agent's egress.
4. Test with a lightweight ERP call from the agent environment. Expected: the call succeeds.
5. Document the egress addresses alongside the agent's runbook so future moves update the allowlist. Expected: no repeat of the block after infrastructure changes.

## When to use

- An agent's ERP calls fail with allowlist or network-policy denials.
- The agent runs on infrastructure with dynamic egress addresses.

## When not to use

- The ERP rejects the agent's credentials (an authentication problem).
- The ERP is unreachable for everyone (an ERP outage).

## Tool compatibility

- NetSuite, SAP, and IP-allowlisted ERPs; NAT gateways and egress proxies.

## Variant phrasings

### ERP blocked agent IP

Same failure, shorter wording.

### Egress not allowlisted for ERP access

The network-policy phrasing.

## Why it happens

ERPs restrict API access to known source addresses. Cloud agents with dynamic egress present a different address per run, so the allowlist never matches.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_b8IxgIFY9Af8EKguBXi3uw