How should security teams use activity-based access control without replacing RBAC entirely?

Why This Matters for Security Teams

Activity-based access control is most useful when organisations already have RBAC in place but need a second decision layer for risky actions. RBAC is still the baseline for entitlement assignment, yet it cannot judge whether a specific request is safe in the moment. That gap matters because non-human identities often hold broad, long-lived access and are a frequent source of exposure; NHI Management Group notes that 97% of NHIs carry excessive privileges in its Ultimate Guide to NHIs.

Security teams get into trouble when they treat RBAC as a complete control rather than a starting point. For humans, static roles are usually stable enough to review periodically. For machine identities, scripts, integrations, and agents, the actual risk depends on runtime context: what is being accessed, from where, with what token, and during what session. That is why behavioural checks are increasingly used alongside RBAC, not instead of it. OWASP’s Non-Human Identity Top 10 reinforces the need to reduce standing privilege and control how NHIs act after authentication. In practice, many security teams encounter abuse only after a token has already been reused, not through intentional access review.

How It Works in Practice

The cleanest model is layered. RBAC assigns the baseline entitlement set, while activity-based controls decide whether a task is allowed at session time. That means a service account or agent can be placed in a role such as “billing-read” or “deploy-operator,” but each action still passes a contextual policy check before it is executed.

Common inputs to that check include request time, source workload, destination system, command type, data sensitivity, anomaly score, and whether the credential is fresh. For machine identities, current guidance suggests short-lived credentials and workload identity should be the default, because long-lived secrets are harder to bound and revoke. This is consistent with the broader NHI lifecycle guidance in Ultimate Guide to NHIs — Key Challenges and Risks, especially where secrets spread into code, CI/CD systems, and third-party tools.

• Use RBAC to define the narrowest durable role that a workload truly needs.
• Use activity-based rules to permit or deny each sensitive action at runtime.
• Prefer short-lived tokens, step-up checks, and automated revocation for risky sessions.
• Log the policy decision, the context used, and the action outcome for later review.

For policy evaluation, teams often use policy-as-code so the decision is consistent and auditable. NIST’s Zero Trust Architecture guidance and the PCI DSS v4.0 expectation for tighter control over privileged access both support this direction, though there is no universal standard for the exact rule format yet. These controls tend to break down when legacy apps cannot pass request context to the policy engine because the decision then falls back to coarse allow or deny logic.

Common Variations and Edge Cases

Tighter activity-based control often increases operational overhead, requiring organisations to balance stronger misuse prevention against slower delivery and more policy maintenance. That tradeoff is especially visible in high-volume automation, where overly strict checks can break legitimate batch jobs or orchestration flows.

One common variation is to use behavioural controls only for high-risk actions, such as secret retrieval, privilege escalation, money movement, production changes, or cross-tenant access. That keeps day-to-day operations stable while still protecting the actions that matter most. Another is to apply different thresholds by identity type: a human session may tolerate a broader set of exceptions, while an autonomous workload should face stricter runtime boundaries because its behaviour can change faster and chain tools in unpredictable ways.

Best practice is evolving for environments with AI agents and multi-step automation. In those settings, activity-based access control is not a replacement for RBAC, but a runtime safety layer that can stop an agent from using an otherwise valid entitlement in an unsafe way. Organisations should also avoid assuming that every control failure is a policy problem; sometimes the real issue is poor identity design, stale secrets, or missing service-to-service visibility. The NHI confidence gap reported in The State of Non-Human Identity Security shows why layered controls are becoming necessary. Control models also become less reliable when third-party OAuth apps and opaque vendor integrations hide the true requester behind shared tokens.

Related resources from NHI Mgmt Group

• How should security teams use context-based access control without creating policy sprawl?
• How should security teams use access control models without creating entitlement sprawl?
• How should security teams use digital identity wallets without weakening access control?
• How should security teams decide whether JIT access is safe for non-human identities?