Run a security and AI posture review
Setup decides your posture once; the rollout guide covers that. This review is the recurring half: the settings that were right at rollout drift as people join, leave, connect agents, and mint tokens, and none of that drift announces itself. Run this quarterly. Each row says what to look at, what healthy looks like, and what a bad answer triggers.
| # | Area | Healthy looks like |
|---|---|---|
| 1 | Access | No unexplained members, no MFA stragglers, deactivations cleaned up |
| 2 | Sessions and tokens | No stale devices, every surviving token names a purpose |
| 3 | Security events | Anomalies explained or escalated, not scrolled past |
| 4 | Agent policy drift | Every enabled destructive operation still has its reason |
| 5 | AI spend | Cost cap set from real usage, not still at the rollout default |
| 6 | Storage and limits | Nothing on the health panel, headroom on every quota |
| 7 | Compliance evidence | Exports run and land where auditors expect them |
1. Access
Section titled “1. Access”Open the Access Review under Security & Compliance and read it as three questions. Who is here that should not be, including guests who outlived their project? Who still has not enrolled in two-factor despite enforcement? Which deactivated members kept residue, like team or reviewer seats that SCIM deactivation deliberately preserves for reactivation?
Check seats and guests in the same pass; removed people free seats, and the bill follows.
A bad answer triggers: removal or role demotion, not a note to revisit.
2. Sessions and tokens
Section titled “2. Sessions and tokens”Two lifecycles, and the distinction is the whole review: signing everyone out kills sessions and connected-app tokens, but personal access tokens survive it, each with its own expiry and revocation. So review them separately:
- Sessions and devices: confirm the idle timeout and session cap still match your policy, and that the connected-app token lifetime is a decision rather than the default.
- API tokens: list every live token and connected agent. A token nobody can name a purpose for is revoked, not investigated; a legitimate owner will notice and mint a scoped replacement, which is the cheapest audit there is.
A bad answer triggers: revocation. It is reversible by re-minting; a leaked token is not.
3. Security events
Section titled “3. Security events”Sweep the Security Events log and audit logs for the period. Anomalous is anything you cannot explain in one sentence: sign-ins from unexpected places, permission changes nobody remembers, invitations nobody sent, exports at odd hours. The Client column tells you whether an action came from the web app, a companion, or an agent over MCP, which is often the explanation by itself.
A bad answer triggers: an explanation before the review closes, or an escalation. The one failure mode this section exists to prevent is scrolling past.
4. Agent policy drift
Section titled “4. Agent policy drift”Agent controls are deny-by-default, so the review question is not “what should we turn off” but “what got turned on since last time, and does its reason still hold?”
- What agents can delete: every enabled destructive operation was a deliberate opt-in; the audit trail records who enabled it and when. If nobody can restate the reason, disable it and see who asks.
- Agent action limits: confirm the contextual rules still describe how your teams actually use agents.
- Agent activity: spot-check that agent work is landing in the same review habits as human work, especially on projects with external agents connected.
A bad answer triggers: disabling the operation. Deny-by-default is the posture; re-enabling is cheap and deliberate.
5. AI spend
Section titled “5. AI spend”The token budget is a one-time bonus plus purchased credit, so spend is bounded by design and this is a tuning pass, not a fire drill. The rollout guide defers the monthly cost cap until real usage exists; by the first review, it exists. Set the cap under AI & Usage from what a normal month actually costs, and choose warn versus block deliberately: warn for teams where AI is in the critical path, block where budget certainty matters more than an interrupted request.
A bad answer triggers: setting the cap. “Still unset” is only correct while usage is still too new to number.
6. Storage and limits
Section titled “6. Storage and limits”Open workspace health, which watches failing integrations, plan limits, and low AI tokens between your reviews, and clear whatever it shows. Check live storage usage against the quota in Organization settings while you are there. For where every limit sits by plan, use compare plans and upgrade rather than memory; the comparison stays current and memory does not.
A bad answer triggers: cleanup first, upgrade second. Quota pressure is sometimes real growth and sometimes an import nobody pruned.
7. Compliance evidence
Section titled “7. Compliance evidence”If auditors are in your picture, confirm compliance evidence exports run on the cadence your regime expects and land where your GRC tooling reads them. An export that silently stopped in month two is discovered in month eleven otherwise, which is the most expensive possible time.
A bad answer triggers: fixing the pipeline now and backfilling the gap, dated honestly.
Why quarterly? Monthly reviews get skipped and yearly ones find drift too old to reconstruct. Quarterly is the longest interval at which “who enabled this and why” still has a findable answer. Regulated teams may need their regime’s cadence instead.
Who runs it, Owner or Admin? An Admin can run every section. Two rows may need the Owner: the permissions matrix is Owner-editable by default, and some billing actions are Owner-gated. The best pattern is an Admin running the review and an Owner receiving the one-paragraph summary.
We just finished the rollout guide. Do we need this already? Book it for one quarter out and skip it until then. The review earns its keep against drift, and a freshly rolled-out organization has not had time to drift yet.
Was this helpful?
Thanks for your feedback!