Guides
Practical Guides, Not Just Positioning.
Three implementation guides for the migrations security teams actually run: retiring standing privilege, governing AI agents, and building an access trail that holds up under audit.
Guide 1
Migrating From Standing Privilege to Just-in-Time Access
A phased approach to retiring standing admin credentials without breaking the workflows your teams depend on.
Guide 2
Deploying AI Agent Governance at the MCP Chokepoint
How to bring AI agents and MCP servers under authorization control without slowing down the teams building on them.
Guide 3
Building an Audit-Ready Access Trail for SOC 2 and ISO 27001
What auditors actually ask for, and how to have the answer ready before the request comes in.
Guide
Migrating From Standing Privilege to Just-in-Time Access
A phased approach to retiring standing admin credentials without breaking the workflows your teams depend on.
1. Inventory before you touch anything
Start with discovery, not policy. Most organizations underestimate how many standing-privilege accounts exist by a wide margin, because service accounts and local admin rights accumulate outside any formal request process. Whiteswan's agents and gateways discover privileged accounts, service accounts, and their actual usage patterns before you change a single permission.
2. Rank by blast radius, not by ease
It's tempting to start migration with the easiest accounts to convert. Start instead with the accounts that can reach the most sensitive systems — domain admin, cloud root, CI/CD deploy keys — even if they're harder to migrate. That's where standing access carries the most risk per day it remains standing.
3. Run JIT and standing access in parallel, briefly
Don't flip a switch. Enable just-in-time elevation alongside existing standing access for a defined window — typically two to four weeks — so you can validate that legitimate workflows aren't disrupted before revoking the standing grant.
4. Revoke standing access on a schedule, not an exception basis
Once JIT elevation is validated for a given account or role, revoke the standing grant on a fixed date rather than waiting for a quiet moment. Migrations that depend on finding the perfect time to revoke access rarely finish.
5. Instrument the audit trail from day one
The value of moving to JIT access compounds when every elevation is logged as it happens. Make sure your audit trail is live before migration starts, not bolted on afterward — it's also your evidence that the migration is actually reducing standing exposure over time.
Guide
Deploying AI Agent Governance at the MCP Chokepoint
How to bring AI agents and MCP servers under authorization control without slowing down the teams building on them.
1. Find every MCP server before you govern any of them
AI agents and MCP servers are typically deployed by engineering and AI teams faster than security can inventory them. Start with discovery across cloud, on-prem, and developer environments — you cannot govern what you cannot see.
2. Attest identity at spawn, not at first use
Every AI agent should receive a cryptographic identity — Whiteswan uses SPIFFE/SPIRE — the moment it's instantiated, not the first time it tries to call a sensitive tool. Retrofitting identity onto an agent that's already running creates a gap attackers can operate in.
3. Declare policy before you declare success
An MCP server without an explicit permit/deny policy is not governed, even if it's inventoried and attested. Define what each agent is allowed to call, on which systems, before treating it as production-ready.
4. Inspect at the call layer, not just at connection time
Approving a connection once and then trusting every subsequent tool call is how standing privilege re-enters agentic systems. Per-call inspection — evaluating each tool invocation against policy — is what keeps an agent's blast radius bounded to what it actually needs for that action.
5. Build the answer to the five questions before you're asked
Who authorized this agent? What is it permitted to do? Who approved those permissions and when? What did it actually do? Can you revoke its access right now? If you can't answer all five today, that's the gap to close first.
Guide
Building an Audit-Ready Access Trail for SOC 2 and ISO 27001
What auditors actually ask for, and how to have the answer ready before the request comes in.
1. Log the decision, not just the outcome
Auditors don't just want to know that access was granted — they want to know why, under what policy, and who or what triggered the request. A log line that says 'access granted' without the decision context behind it rarely satisfies an assessor.
2. Timestamp everything, including denials
A complete access trail includes every request your policy engine denied, not just the ones it approved. Denied requests are often the most interesting evidence you have that your controls are actually doing something.
3. Map every access decision to a control, automatically
SOC 2 and ISO 27001 evidence requests come mapped to specific control numbers. Save your team the quarterly scramble by generating evidence that's already tagged to the control it satisfies, not raw logs an auditor has to interpret.
4. Keep human and machine identities in the same trail
Auditors increasingly ask about service accounts and AI agents in the same breath as human privileged users. A trail that only covers human sessions leaves a visible gap the moment that question comes up.
5. Make the evidence exportable on demand, not on a schedule
The organizations that handle audits best are the ones that can produce a clean access report the day it's requested, not the ones that start assembling one when the audit notice arrives.
Want a Second Set of Eyes on Your Migration?