CrowdStrike used Fal.Con 2026 to announce the Agentic Identity Provider, positioning it as the foundation for AI agent identity security on the Falcon platform. The pitch, on its face, sounds like every other “NHI governance” post that’s been published this year — non-human identities are growing, agents need scoped credentials, treat them like workload identities not shared service accounts. I’ve written that advice myself. What’s actually new here, and worth separating from the boilerplate, is the mechanism: replacing standing privileges with continuous, per-action authorization, built on technology from CrowdStrike’s SGNL acquisition.

Why “standing privileges” is the wrong model for agents

A standing privilege is a grant that exists whether or not it’s being used right now — an API key with deploy scope sits in a secrets manager for months, valid the entire time, regardless of whether the holder is actively deploying anything. That model is fine for humans because humans are rate-limited by attention: a compromised human credential still requires someone to notice and act on it, and humans don’t naturally call an API 500 times a minute.

Agents break that assumption completely. An agent holding a standing deploy credential can use it the moment it’s compromised, prompt-injected, or simply reasons its way into a bad plan — at machine speed, with no attention bottleneck to slow it down. This is the same class of problem I wrote about with Cloudflare’s MCP traffic detection a couple weeks back: the anomaly isn’t in any single call, it’s in the volume and autonomy. Standing privileges make that anomaly exploitable, because the credential is live and waiting regardless of context.

CrowdStrike’s framing: dynamically grant, deny, and revoke access based on real-time risk, authorizing every agent action based on who owns it, who is calling it, and the risk of the action itself — not a static policy decided once at provisioning time.

What “continuous authorization” looks like in practice

The mental shift is from “does this credential have the scope” (checked once, at issuance) to “should this specific action be allowed, right now, given current context” (checked per-call). Roughly, the difference looks like this:

# Standing-privilege model
token = issue_token(agent="build-agent", scopes=["read", "write", "deploy"])
# token is valid until expiry or manual revocation — full scope, always

agent.deploy(token)  # succeeds any time the token hasn't expired


# Continuous-authorization model
def authorize(agent, action, context):
    risk = evaluate_risk(
        who_owns_agent=agent.owner,
        who_is_calling=context.caller_chain,
        action_sensitivity=action.risk_tier,
        recent_behavior=agent.session_anomaly_score,
    )
    return risk.decision  # grant / deny / step-up, decided per call

if authorize(build_agent, "deploy", current_context) == "grant":
    build_agent.deploy()

The second model has no moment where a leaked or misused credential is simply “still good” — every action re-derives its own authorization from current risk signals, which means an agent behaving anomalously mid-session (unusual call volume, an action outside its normal pattern, a caller chain that doesn’t match its owner) can be cut off before the next action, not after a post-incident credential rotation.

Where this connects to what I’m already running

This lands the same week as Anthropic’s mid-conversation tool changes going into beta, and the two combine into a pattern worth naming explicitly: capability should be a function of current, approved context, re-evaluated continuously, not a fixed grant handed out at session start. I described a version of this by hand in my own build-agent setup — start with read-only tools, add deploy only after a human approves a plan. CrowdStrike’s pitch is that this should be infrastructure, not something every team hand-rolls with an if plan_approved check scattered through agent code.

That distinction matters at scale. My hand-rolled version works for one agent I built and understand completely. It does not work as an organizational control when there are twenty teams each writing their own version of “check before deploy,” with twenty different definitions of what counts as suspicious. A platform-level continuous-authorization layer — whether it’s this one, an internal equivalent, or a competitor’s — is what turns “the agent shouldn’t have standing deploy access” from a good practice into an enforced one.

What I’d actually push on before adopting

Before treating this as ready to sit in front of production agent traffic, the honest questions:

  1. Latency budget. Per-action risk evaluation adds a network hop and a decision to every tool call. For an agent making dozens of calls per task, that overhead needs to be single-digit milliseconds or it becomes the new bottleneck — worth benchmarking before rollout, not after.
  2. What “risk” is actually scored on. Real-time risk decisions are only as good as the signal feeding them. If the anomaly model hasn’t seen your agent’s normal behavior yet, early false-positive denials will train teams to route around the control rather than trust it — the same failure mode as overly aggressive spam filters.
  3. Failure mode when the identity provider itself is unreachable. Continuous authorization means every action depends on a live decision. Fail-open defeats the purpose; fail-closed means an IdP outage takes down every agent that depends on it. Neither answer is free, and it needs to be a deliberate choice, not a default nobody reviewed.

The takeaway

Most NHI advice this year has been about classification and hygiene — inventory your service accounts, use workload identity instead of shared credentials, track what’s calling what. That’s necessary but static. What CrowdStrike is pointing at is the next layer: even well-scoped, well-inventoried agent credentials are still a liability if they’re valid at rest. The fix isn’t a better-organized standing privilege — it’s removing the “standing” part entirely and re-deciding authorization on every action. Whether or not this specific product is the one that wins that space, the architecture pattern is the one worth adopting in your own agent infrastructure now, before an incident makes the case for you.

Export for reading

Comments