NotC2: who authorizes the path between AWS services?
A familiar destination does not establish that an operation was authorized. NotC2 research helps assess the identities and service relationships that can complete an action.
Auf Portugiesisch lesenBy Pentesty
A demonstration that assumes prior access
In November 6, 2026 research, Varonis presented NotC2: a proof of concept assuming prior AWS credentials and combining SQS, Lambda, SNS and Bedrock. The model operates within assigned permissions. The account demonstrates neither a Bedrock flaw nor a campaign against businesses.
The research distinguishes deployment and runtime. SNS delivers results after external subscription confirmation, a different path from Lambda’s direct egress. This November 9 analysis proposes enterprise criteria without reproducing the framework.
Map the operation before approving the integration
Start with the legitimate flow: which person requests the task, which queue receives it, which function may act and which destination receives the result. Assign an owner to each relationship. A useful diagram also identifies the operation that should be denied when one of these elements changes.
Keep separate authority records for deployment and operation. A team may need to deliver a function without being able to expand the role it receives. Another may operate a service without creating new delivery destinations. Approval should explain those differences through defined resources and limits, rather than relying on the provider’s familiar name.
Before release, compare the delivered configuration with the approved set of relationships: role, queue, function, topic and recipient. Preserve the examined version and the decision record. If a change adds a destination or expands authority, define who must approve it again. Earlier approval should not automatically carry over to an integration that has acquired different capabilities.
Test the boundary at the resource making the decision
In an authorized laboratory account, use fictional data and test identities to compare a permitted operation with one outside scope. Observe the decision at the receiving resource. A model’s statement that it followed a rule cannot replace evidence that the service refused the prohibited action.
Include an identity transition in the exercise: a legitimately initiated task should remain constrained as it passes between components. Record the effective role, requested operation, resource and decision. Correlation identifiers help connect records without copying secrets or sensitive content into the report.
Include service-mediated delivery in the assessment
Plan one scenario in which an approved destination remains available and another in which an identity tries to add an unapproved recipient. Use only destinations controlled by the team. Demonstrate which control prevents the change and that legitimate delivery continues to work.
This verification is separate from testing a function’s direct internet connection. Intermediate services also make configuration and access decisions. Connect the network owner with the owners of permissions and messaging services, so that a declared restriction has an identified enforcement point throughout the flow.
Include a failure of the authorized recipient without redirecting messages to third parties. Check which error reaches the team, who may change configuration and how operation returns to the approved state. Establish those responsibilities before an operational emergency, when an improvised workaround could create a path with no clear owner or sufficient evidence to assess its effects.
Plan evidence before you need it
Varonis distinguishes log sources and information requiring specific configuration. Observing a call does not mean seeing its content. In the assessment, specify which conclusion each record can support.
Prepare a synthetic sequence with known timestamps and check whether the team can reconstruct the requester, function, operation and recipient. Measure retention gaps and analyst access as well. At the end of the exercise, revoke the test identity and confirm that a new attempt is rejected by the responsible service.
Our article on agent network and action boundaries applies the same requirement for evidence beyond the AI’s account. The additional focus here is service relationships and the roles authorizing them. Release depends on demonstrating these boundaries and documenting exceptions that still require a decision.
Frequently asked questions
Is NotC2 an Amazon Bedrock vulnerability?
The source presents a proof of concept involving prior credentials and AWS permissions, without demonstrating a Bedrock flaw or customer campaign.
Does the AI grant additional permissions?
In the demonstration, operations remain limited to assigned authority.
Does restricting Lambda’s direct egress cover delivery?
It does not cover the SNS path. Assess recipient configuration and publication authorization.
How can a team test without deploying a malicious channel?
Use harmless operations, synthetic identities and controlled destinations. Compare permissions and refusals at each resource without reproducing the command-and-control framework.
Sources and references
Original Pentesty analysis, published November 9, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.