Testing Group Claim Size Limits Before an Agent Owns Too Many

Decide which failure you are hunting before writing any code. Four distinct ceilings behave differently.

The last row is the one most teams forget. Web servers enforce independent limits regardless of what the IdP emits; the Broadcom guidance lists roughly 8 KB for Apache, 4 to 8 KB for Nginx, 8 to 16 KB for IIS and 8 to 48 KB for Tomcat. Send a large response via HTTP-Redirect and the assertion travels as a URL parameter, where URL length limits produce failures that look nothing like a size problem.

Protocol choice changes the number too. SP-initiated flows correlate the response to an AuthnRequest while IdP-initiated responses carry less correlation state, and validation differs between them Scalekit's comparison of the two flows. If production uses a client-credentials OIDC path but staging exercises an interactive SAML POST, you are measuring the wrong ceiling.

A test against a toy IdP proves nothing, because the limits live in configuration you have not replicated. Match production on four dimensions:

1. Same IdP product and tier, with identical group claim configuration. If production sends all groups, staging sends all groups.
2. Same baseline membership, because a search starting from zero reveals the ceiling but not your headroom.
3. Same token lifetimes, signing and encryption settings, since encryption inflates payload size.
4. Same clock discipline. Assertions carry NotBefore and NotOnOrAfter values, and a few minutes of skew between IdP and SP produces intermittent rejections that mimic nothing else the SAML clock skew explainer. A flaky "randomly fails at 40 groups" result is usually skew.

Keep the harness deterministic. Generate groups from a template with fixed-length names so each addition costs a predictable number of bytes. s3-read and finance-accounts-payable-emea-readonly differ by 30 characters, and at 600 groups that is 18 KB, enough to move you across a threshold. Record the byte delta per group and you can predict the ceiling rather than only discovering it.

The NIST digital identity guidelines are worth reading for framing: they treat authenticator binding and lifecycle state as things requiring records of when binding happened and deliberate handling when it changes NIST SP 800-63B-4. An agent's group membership is exactly that lifecycle state. The 2017 edition of the same publication is withdrawn and superseded in its entirety, so consult the current version the superseded SP 800-63B.

Phase one doubles the count each iteration and stops at the first failure.

counts = [1, 2, 4, 8, 16, 32, 64, 128, 256, 384, 512, 768, 1024]

for n in counts:
    provision the agent identity with exactly n groups
    request the token or start the SSO flow
    record:
      http_status
      raw_payload_bytes        # body size, or extracted assertion/token size
      claim_present (bool)     # did the groups claim survive?
      claim_count              # how many groups arrived
      first_error_string
    if http_status >= 400 or claim_count != n:
        first_failure = n
        last_success  = previous n
        break

Run each count three times. Identity providers cache, service providers cache, and issuance sometimes depends on which node answers. A count that fails twice and passes once is a signal worth recording.

Use two stop conditions, not one. Stop on request failure, and stop when the arrived claim count differs from what you provisioned. The second catches silent omission. If you provision 151 and receive 150, you found a count cap, not a size cap.

Send traffic through the real path. Post the assertion to your actual SP endpoint through the actual proxy chain with realistic cookie and header sizes. A curl call straight to the Assertion Consumer Service bypasses the layer most likely to truncate.

With a bracket in hand, bisection needs at most eight more probes across a range of 256, each one identity change plus one token request.

def find_ceiling(passes, fails, probe, max_rounds=12):
    lo, hi = passes, fails          # lo passes, hi fails, invariant
    history = []
    for _ in range(max_rounds):
        if hi - lo <= 1:
            break
        mid = (lo + hi) // 2
        ok, observed = probe(mid)   # ok = no error AND claim_count == mid
        history.append((mid, ok, observed))
        if ok:
            lo = mid
        else:
            hi = mid
    return lo, hi, history

The invariant is that lo always passes and hi always fails. When the gap reaches one, lo is the ceiling: the largest count yielding a complete, accepted claim. Log the history, because the failure shape identifies which ceiling you found.

• Errors above N, complete claims below N. A size limit. The group ceiling holds only while name lengths hold, so record the byte size at the ceiling as the real budget.
• Success above N with no groups claim, or with 150 groups when you sent 151. A count cap with silent omission. The number is the limit, and your authorization logic must handle an overage indicator rather than read an empty list as "no access."
• Success above N with a stable prefix of groups. Truncation. Worse than omission, because the app may grant access on surviving groups while the rest vanished.
• Failures alternate rather than track count. Suspect skew, caching, or IdP nodes with different configuration. Fix the harness before trusting a number.
• Failure only through the proxy, never direct. You found the web server header limit. Test with the proxy in the loop and record the byte size where it breaks.

Bisection assumes monotonicity, which normally holds with one exception. Some IdPs switch strategy when a claim is oversized, truncating and adding a link to fetch groups via an API, so the same oversized claim can yield a valid token under one configuration and a hard error under another. Confirm which behavior yours exhibits, and re-run the top of the failing range once with a clean cache.

The last row deserves emphasis. Every character needing escaping in XML or a URL expands the payload. Groups named with ampersands, spaces, or non-ASCII characters can cross a threshold with far fewer memberships than a test using clean names like grp-0001 suggested. Generate the worst case your directory allows, not the tidiest.

You have four levers. They differ in cost, availability, and how much they change your agent's design.

Shrink each group's representation. Use object identifiers rather than display names where the protocol allows, and drop redundant prefixes. A GUID is 36 characters; a fully qualified path can exceed 60. At 200 groups that is nearly 5 KB, a fixed amount of headroom you can state as a number.

Change what you send, not how many groups exist. Microsoft recommends restricting claims to groups assigned to the application, or using a group filter, and recommends application roles over groups for new applications the platform supports Microsoft's guidance on group claims and app roles. The principle generalizes: an agent should receive the groups that matter to its task, not every group it belongs to. This is usually the correct structural fix.

Use nesting or indirection. If the platform supports nested groups or a directory role standing in for a set of resource groups, the claim can stay flat while real membership grows. Microsoft counts nested groups toward its limits, so nesting only helps if it collapses many leaf groups into few emitted ones. Verify against the provider rather than assuming.

Split the agent into narrower identities. This is the fix that scales once the others are exhausted. Replace one overprivileged agent with several, each scoped to bounded resources, each with its own membership and owner. This aligns with least privilege and with just-in-time access, which the CSA framework positions as replacing standing agent privileges with intent-declared, time-bound grants.

The decision rule: if the measured ceiling sits comfortably above current membership plus a growth margin, do nothing and monitor. If you are within 20 percent of it, change what you send. If you are over it, or will be within one planning cycle, split the identity. A single identity with 400 memberships is a blast radius, not just a token problem.

Provisioning discipline keeps you off the ceiling. Treating agents as managed identities with automated create, update and deprovision steps, rather than hand-built service accounts, is the difference between a group list that grows deliberately and one nobody pruned LoginRadius on SCIM provisioning for agents. An inventory recording each identity's credential type, scope, owner, and deprovisioning criteria is the minimum for noticing drift Sweet Security's non-human identity guidance. Whether an agent should carry a human-like identity or a workload identity also changes how many groups it plausibly needs Aembit's discussion of agent identity types.

Teams running many agents against different model providers usually face identity work and model-access work together. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key with prepaid USD pricing, keeping the agent-to-model path consistent while you rework authentication: https://quantaintelligence.ai/inference.

A test that runs once is already stale. Membership grows, group names change, and someone edits a claim configuration.

• Run the full search when the IdP claim configuration, the SP's documented limit, the group naming convention, or the provisioning source changes.
• Run a nightly headroom check. Provision the agent at 80 percent of the recorded ceiling and assert the full claim arrives. One token request catches drift.
• Store the ceiling with its context. "412 groups" means nothing without the IdP, the claim configuration, average group name length, and which SP's limit applied.
• Alert when claim count falls below membership count. This is the production detector for silent omission.
• Test deprovisioning. Confirm that removing groups shrinks the claim, because a claim that only grows is a ceiling you will reach regardless.

Two adjacent controls belong beside this work. Short-lived credentials bound how long a stale large claim stays useful, and Microsoft notes that access tokens default to a one-hour lifetime, which limits how quickly a bad claim stops mattering Microsoft's access revocation guide. Break-glass identities deserve the same scrutiny as agents, including exclusions from policies that could block the recovery they exist for Microsoft's emergency access guidance. When sessions or factors change, invalidation should be a deliberate state transition, with sessions bound to a security epoch that increments on change the security epoch walkthrough.

If you want the harness design reviewed before you build it, a free 30-minute call covering your goals and a tailored recommendation is the fastest route: https://quantaintelligence.ai/calendar.