The admin console of an AI coding assistant decides which developers get agent capabilities, which extensions and MCP servers those agents may load, and which tokens can act on the organisation's code, so whoever controls that console controls a large part of the software supply chain. Most security work on coding assistants focuses on the developer's machine and the pull request. This guide looks at the estate from the administrator's side: the organisation-level roles in the console, governance of the extension and MCP server allow list, the lifecycle of seats and tokens, audit log retention and what happens when the product is retired or replaced. It is vendor-neutral and applies to hosted, private cloud and self-hosted assistants. For the rollout itself, capability tiers, context exclusions and pipeline guardrails, see the AI coding assistant rollout playbook; this page assumes the assistant is already in use.
Key takeaways
- Console administrators are supply chain administrators. They can switch on agent modes, approve new tools and change data handling for every developer at once, so the role needs privileged account controls and a second approver for high impact changes.
- The allow list is a living control, not a one-off approval. Approved extensions and MCP servers change after approval, so pin versions, snapshot tool definitions and re-review on every change.
- Seats are identities. Assign them only through the identity provider and remove them in the same leaver process as other access, or ex-staff keep a route to the organisation's code and model budget.
- Every token the estate issues needs an owner and an end date. Admin API tokens, CI agent tokens and personal tokens created for the assistant are non-human identities that outlive the people who made them.
- Audit logs leave with the contract unless you export them. Stream console and usage logs to storage the assistant's admins cannot alter, and plan retention and retirement before you need the evidence.
The admin plane at a glance
Products differ, but most coding assistant estates share the components below. Each carries identities that an attacker would like to hold. The developer-side credentials (local token files and MCP configuration on laptops) are covered in How to audit AI coding assistant tokens and config files.
| Component | What it controls | Identities and secrets involved | Primary control |
|---|---|---|---|
| Organisation admin console | Enabled features and agent modes, model choice, data retention, policy lock, billing | Owners, administrators, billing managers | SSO with phishing-resistant MFA, few owners, two-person approval for policy changes |
| Management or admin API | Scripted seat assignment, policy export, usage and audit retrieval | Admin API tokens, service accounts, SCIM tokens | One token per integration, narrowest scope, expiry, vaulted storage |
| Seat assignment | Who can use the assistant and at which tier | Workforce identities from the IdP | Group-based assignment through SCIM, no direct invites |
| Extension and MCP allow list | Which plugins, MCP servers and tools agents may load | Tool credentials, OAuth grants to remote MCP servers | Registry of approved items with owner, version pin and review date |
| Code host and CI integrations | Review bots, cloud agents opening pull requests, indexing of repositories | App installations, bot tokens, CI agent credentials | Repository-scoped installs, least privilege, approval gate on pushes |
| Audit and usage logs | Evidence of admin actions, policy changes and use | Log export service accounts, analysts | Export to a SIEM the console admins cannot modify, defined retention |
The relevant attacker techniques include ATT&CK T1078.004 Cloud Accounts for a hijacked admin login, T1098 Account Manipulation for role grants and new tokens, T1528 Steal Application Access Token for integration tokens and T1195.002 Compromise Software Supply Chain for a poisoned extension. OWASP LLM03:2025 Supply Chain and LLM06:2025 Excessive Agency describe the AI side.
Administrative roles and separation of duties
The joint guidance Deploying AI Systems Securely (NSA AISC, CISA, FBI and Five Eyes partners, April 2024) asks for distinct user and administrator roles, phishing-resistant MFA for administrative access, privileged access workstations for administering AI systems, and role or preferably attribute based access control. Applied to a coding assistant console, that means splitting duties along these lines.
| Role | Can do | Should not be able to do |
|---|---|---|
| Organisation owner (break-glass) | Recover the tenant, transfer ownership, change SSO | Be used for daily work; held by two named people under split control |
| Policy administrator | Enable or disable features and agent modes, set data retention, lock settings | Assign seats or approve tools alone |
| Seat and licence manager | Map IdP groups to seat tiers, run reports | Change policy or create admin tokens |
| Tool approver | Add, pin or remove extensions and MCP servers in the allow list | Change policy locks or log settings |
| Integration owner | Install and scope code host and CI integrations for a business unit | Grant organisation-wide repository access |
| Audit reader | Read and export audit and usage logs | Change anything |
- Keep owners few and dormant: two owner accounts, used only for tenant recovery, with alerts on every sign-in. See the Break-Glass Account Guide.
- Two-person approval for high impact changes: enabling an autonomous agent tier, allowing unlisted tools, turning on prompt or code retention at the provider, or widening a code host integration to all repositories should need a second approver (AC-5).
- Admin automation has an owner: scripts that assign seats or pull usage data hold administrator rights through the admin API. Give each its own identity and alert when it is used from an unexpected network.
- Review quarterly: list everyone holding a console role and every admin API token, and remove what has no current owner (AC-2, AC-6(5)).
Extension and MCP allowlisting governance
The OWASP Secure Coding with AI Cheat Sheet advises maintaining an allow list of approved MCP servers and tools, not letting agents discover and connect to servers automatically without approval, not connecting to servers from untrusted sources without security review, and using snapshot-and-diff checks to catch "rug-pull" changes to a tool's behaviour after approval. The MCP specification's security best practices add that one-click local server configuration must show the exact command before running it, and that servers must not accept tokens that were not issued to them. The governance question is who keeps that list true over time.
| Stage | What happens | Evidence to keep |
|---|---|---|
| Request | A team asks for an extension or MCP server with a business reason and data classification | Request record, named owner |
| Review | Publisher, source, permissions, network destinations, credentials it needs, tool descriptions read for embedded instructions | Review notes, risk rating. See the MCP Server Trust Assessment |
| Approve and pin | Added to the console allow list at a pinned version or digest, with scopes it may request | Version, hash or digest, tool definition snapshot |
| Change | New version or changed tool definitions trigger re-review before the pin moves | Diff of tool definitions, approver |
| Re-certify | Owner confirms it is still needed, at least yearly | Attestation, usage count |
| Remove | Removed from the allow list, grants and tokens revoked, devices checked | Removal date, revocation record |
- Default deny at the console: where the product supports an organisation-level allow list or registry, enforce it so developers cannot add servers locally. Where it does not, enforce through endpoint management and detect with How to audit MCP servers on developer laptops (CM-7(5), CM-11).
- Pin, do not float: auto-updating extensions turn one bad release into an estate-wide event. In the 2026 poisoned editor extension incident a malicious version was live for minutes, yet auto-update installs produced thousands of activations, and the payload harvested vault, cloud and source control tokens from developer machines.
- One inventory: record each approved item once, with owner, version, scopes and the credentials it uses, in the MCP Server Inventory Template or an equivalent register.
- Remote servers get their own identity: prefer remote MCP servers that use OAuth with scoped, short-lived tokens issued for that server over static keys pasted into configuration. The specification lists wildcard or omnibus scopes as a common mistake.
Seat lifecycle
A seat is access to the organisation's code context, model budget and sometimes cloud agents that act on repositories. Treat it like any other entitlement in the joiner, mover and leaver process (AC-2, PS-4).
- Joiner: seats come only from IdP groups mapped to a capability tier, provisioned by SCIM. SCIM 2.0 (RFC 7644, Standards Track) defines DELETE for removing a user resource, after which the provider must return 404 for that resource. Block direct email invitations and personal sign-up on corporate domains. See the SCIM Provisioning Guide.
- Mover: a developer moving out of a team with agent tier access drops back to the tier of the new group automatically. Review any repositories the user connected to cloud agents.
- Leaver: the IdP disable removes the seat, ends sessions and should revoke tokens the user created for the assistant. Confirm in the console audit log, not only in the IdP. See the Employee Offboarding Security Checklist.
- Dormant seats: reclaim seats with no use in 60 or 90 days (our recommendation). Dormant seats cost money and are the accounts nobody notices being used.
- Contractors and partners: separate groups with end dates, no autonomous agent tier by default, and no access to repositories outside the engagement.
Token lifecycle
A coding assistant estate creates several kinds of non-human credential. Each one needs an owner, a scope, storage in a vault and an expiry (IA-4, IA-5). The OWASP cheat sheet asks for ephemeral credentials scoped to the current task rather than long-lived developer credentials, and for CI agent credentials scoped to the minimum required.
| Credential | Typical holder | Lifetime to aim for | Revoke when |
|---|---|---|---|
| Admin API token | Seat automation, reporting scripts | 90 days or less, rotated with overlap | Script retired, owner leaves, use from a new network |
| SCIM provisioning token | The IdP connector | As long as the connector, rotated yearly | IdP change, suspected exposure |
| Code host app or bot credential | Review bot, cloud agent | Short-lived installation tokens where offered | Integration removed, scope review fails |
| CI agent token | Pipeline running an agent | Per run, through workload identity federation where possible | Pipeline changed or retired |
| Personal token created for the assistant | A developer's CLI or IDE | Short expiry enforced by policy | Leaver, lost device, inactivity |
| MCP server OAuth grant | Remote tool on behalf of a user | Short access token, refresh bound to the user | Server removed from allow list, user leaves |
- Enforce expiry where the code host allows it: see How to set expiry policies on personal access tokens.
- Logout is not revocation: deleting a local credential does not end it at the issuer; revoke at the source when a device is lost or a person leaves.
- No shared bot tokens: one credential per integration and per repository scope, so one can be revoked without breaking the rest. The coding assistant extension compromise began with an over-scoped build token that could commit to the extension's own release path.
Audit logs and retention
Deploying AI Systems Securely recommends monitoring configuration for unauthorised changes and keeping log data in immutable storage. OWASP adds audit trails showing which developer approved which AI-generated change, and logging CI agent action metadata, authorisation decisions and outcomes while keeping sensitive content out of the logs.
- Know the three log sources: console audit events (role grants, policy changes, allow list edits, token creation), usage telemetry (who used which feature and model) and code host events for the assistant's apps and bots.
- Export continuously: in-product retention is often shorter than an investigation needs and may depend on the plan. Stream to a SIEM or log store owned by security, not by the console admins (AU-9, AU-12). See the SaaS Audit Log Retention and Licensing Guide.
- Set retention by obligation: keep admin and policy events at least as long as other privileged access records; check sector rules in the Log Retention Requirements Map (AU-11).
- Prompts and code are a separate decision: if prompt or response content is retained anywhere, treat it as source code and personal data, with restricted readers and its own retention period.
Monitoring and detection
| Event | Why it matters | Suggested response |
|---|---|---|
| Owner or admin role granted, or owner sign-in | Full control of policy, tools and tokens | Alert immediately, confirm with a second person |
| Agent tier enabled for a new group or organisation-wide | Command execution for many developers at once | Match to change ticket |
| Allow list change, or a tool used that is not on it | New code running with developer privileges | Confirm approval record; block and investigate if none |
| Data retention or policy lock changed | Code or prompts kept, or developers able to override settings | Critical alert |
| New admin API token or integration with wide repository scope | Persistent access outside SSO | Confirm owner and scope within one working day |
| Seat active for a disabled IdP user | Leaver process gap | Remove seat, revoke tokens, review activity |
| Log export stopped or audit setting changed | Classic step before misuse | Critical alert |
Lifecycle and retirement plan
- Days 1 to 30, inventory: list owners and admins, admin API tokens, integrations and their repository scope, the current extension and MCP allow list (or its absence), seats without an IdP group and log retention. Turn on log export and the critical alerts above. Rollback: none needed, read and alert only.
- Days 31 to 60, admin plane: move admins to SSO with MFA, split roles, vault owner accounts, replace shared admin tokens with one per integration. Change one integration at a time and keep the old token valid until the new one is proven.
- Days 61 to 120, seats and tools: move all seats to SCIM groups, reclaim dormant seats, publish the allow list process and pin versions. Pilot default deny with one business unit in report mode before enforcing; rollback is re-allowing the previous list from the export.
- Ongoing: quarterly review of roles, tokens, integrations and the allow list; yearly owner break-glass test and allow list re-certification.
- Retire or replace: when changing product, export and archive audit logs under the retention policy first, then remove seats, uninstall code host apps, revoke every admin, SCIM, CI and MCP credential the estate issued, ask the supplier for written confirmation of deletion of retained prompts and code (SA-9, MP-6), and remove the old extension from endpoints. Deploying AI Systems Securely calls for irretrievable deletion of components such as cryptographic keys once they are no longer needed. See the NHI Offboarding and Decommissioning Guide.
These timings are NHI Mgmt Group's recommendation; scale them to the size of your estate.
Decision guidance
- Console allow list or endpoint enforcement: a console-level allow list is simpler and travels with the user; endpoint enforcement also covers unmanaged installs and other assistants. Large estates usually need both.
- Hosted or self-hosted: self-hosting keeps code and logs in your environment but makes patching, model serving and log storage yours. With a hosted service, roles, seats, tokens, the allow list and log export remain customer-side controls.
- One assistant or several: each additional product doubles the admin plane to govern. If teams need several, apply the same role model, allow list process and log export to each.
- Small organisations: with one or two admins, compensate with alerts sent outside the admin team, a short allow list reviewed monthly and SCIM from day one.
Detection and measurement
- Admin footprint: number of owners and admins, and owner sign-ins per quarter (target: owner sign-ins only during tests).
- Seat hygiene: percentage of seats assigned through IdP groups (target 100 percent) and dormant seats older than 90 days.
- Token hygiene: percentage of admin, integration and CI credentials with owner and expiry, and age of the oldest one.
- Allow list currency: approved items past their review date, and tools seen on devices that are not on the list.
- Leaver closure: hours from IdP disable to seat removal and token revocation confirmed in the console log.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Threat references |
|---|---|---|---|
| Admin roles and separation | AC-2, AC-5, AC-6(5), IA-2(1) | PR.AA-05 | ATT&CK T1078.004, T1098 |
| Seats and leavers | AC-2(3), PS-4 | PR.AA-01 | ATT&CK T1078.004 |
| Tokens and integrations | IA-4, IA-5 | PR.AA-01 | ATT&CK T1528 |
| Extension and MCP allow list | CM-7(5), CM-11, SR-3 | PR.PS-01, GV.SC-07 | ATT&CK T1195.002; OWASP LLM03:2025, LLM06:2025 |
| Audit logs | AU-6, AU-9, AU-11, AU-12, AC-6(9) | PR.PS-04, DE.CM-09 | Deploying AI Systems Securely: immutable logs |
| Supplier and retirement | SA-9, MP-6 | GV.SC-07 | Deploying AI Systems Securely: irretrievable deletion |
Common failure patterns
- Everyone is an admin: the pilot team kept owner rights after rollout, so any of their accounts can enable agent tiers or new tools for the whole organisation.
- Approved once, trusted forever: an MCP server or extension was reviewed at version one and floats to whatever its publisher ships next.
- Direct invites outside the IdP: seats granted by email survive the leaver process because the IdP never knew about them.
- Integration with all repositories: a review bot or cloud agent was installed organisation-wide for convenience, so one stolen credential reaches every repository.
- Logs only in the product: in-product retention expired before the investigation started, or ended with the contract.
- Retirement by licence lapse: the old assistant's seats expired, but its code host app, admin tokens and endpoint extension were never removed.
Practitioner checklist
- Keep two dormant owner accounts under split control and alert on every owner sign-in.
- Split policy, seat, tool approval, integration and audit roles, with SSO and phishing-resistant MFA for all.
- Require a second approver for agent tier changes, data retention changes and allow list exceptions.
- Run a request, review, pin, re-review and removal process for every extension and MCP server.
- Assign seats only through IdP groups and SCIM, block direct invites and reclaim dormant seats.
- Give every admin, SCIM, integration and CI credential an owner, the narrowest scope and an expiry.
- Stream console, usage and code host logs to a SIEM the console admins cannot alter, with retention set by obligation.
- Alert on role grants, policy changes, allow list edits, wide-scope integrations and stopped log export.
- Review roles, tokens, integrations and the allow list quarterly.
- On retirement, archive logs, then remove seats, apps, tokens and extensions and get written deletion confirmation.
Standards and references
- NSA AISC, CISA, FBI and partners: Deploying AI Systems Securely
- OWASP: Secure Coding with AI Cheat Sheet
- Model Context Protocol: Security Best Practices
- IETF: RFC 7644 System for Cross-domain Identity Management Protocol
- OWASP: Top 10 for LLM Applications 2025
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NCSC: Guidelines for secure AI system development
- MITRE ATT&CK: Compromise Software Supply Chain
Related NHI Mgmt Group resources: AI coding assistant rollout playbook · AI IDE and Coding Agent Security Guide · Enterprise AI Copilot Security Guide · MCP Gateway and MCP Server Governance Guide · AI Coding Agent Incident Playbook