AWS AgentCore policy enforcement weakened or removed

Goal

Detects an Amazon Bedrock AgentCore Policy, PolicyEngine, or GatewayRule resource having its guardrail enforcement weakened or being deleted outright, and separately flags resource-based policy changes on AgentCore resources.

Strategy

This rule monitors CloudTrail management events for bedrock-agentcore.amazonaws.com across two independent cases.

The first case triggers on an UpdatePolicy call that sets enforcementMode to LOG_ONLY or validationMode to IGNORE_ALL_FINDINGS, both of which demote a Policy resource from actively enforcing guardrails on agent tool-call behavior to merely observing or ignoring violations. It also monitors for outright deletion of a Policy, PolicyEngine, or GatewayRule resource through DeletePolicy, DeletePolicyEngine, or DeleteGatewayRule.

AgentCore Policy and PolicyEngine resources constrain what actions an AI agent’s tool calls are permitted to take, so weakening or removing this enforcement is a defense-evasion precursor that can allow subsequent agent behavior to go unconstrained or unvalidated. The second case triggers on PutResourcePolicy or DeleteResourcePolicy against AgentCore resources, which grants or revokes resource-based access such as cross-account invoke permissions.

Triage and response

  • Determine whether {{@userIdentity.arn}} is authorized to modify or delete AgentCore Policy, PolicyEngine, GatewayRule, or resource-based policy configuration for the affected account.
  • Review the specific {{@evt.name}} and request parameters to confirm which control was weakened, which resource was deleted, or which resource-based policy was changed.
  • Check whether the change was applied through infrastructure-as-code or CI/CD tooling rather than a manual console or API call, and whether the calling role name or pattern is consistent with known automation in the account.
  • Search for subsequent AgentCore Runtime invocations, tool-call activity, or cross-account access from the same identity or affected resource following the change to identify whether the weakened or newly granted access was exploited.
  • Confirm with the resource owner whether the change is part of a planned rollout, staged enforcement migration, or deployment, and if not, revert the affected Policy, PolicyEngine, GatewayRule, or resource-based policy to its prior configuration.
  • Review recent IAM policy changes or credential activity for {{@userIdentity.arn}} to rule out a compromised principal making the change.