Disciplines → 3 of 6
Approved tools, governed integrations and context managed as code, so AI works with the organisation's standards and inside its boundaries.
Tooling & Context Engineering decides which AI tools may be used, how they connect to the organisation's systems, and what they are told. It covers tool selection and the approved catalogue, integration through open protocols, agents as non-human identities, and the prompts, skills and context packs that shape every AI output.
Two things determine the quality and safety of AI-assisted work besides the reviewer: the tool and the context it receives. Both are usually unmanaged at first, chosen by individuals and pasted in by hand. This discipline brings them under the controls that already govern software, access and documentation, so a tool can be defended to an auditor and a prompt can be traced like any other change.
| Practice | Today | With Tooling & Context Engineering |
|---|---|---|
| Procurement | Licence, price and security questionnaire | Adds data residency, retention, training use of inputs, audit logs and a documented exit plan |
| Software asset management | Inventory of installed software and licences | Approved AI tool catalogue with tiers of permitted use; integrations and agents registered as assets |
| Identity & access | People and service accounts, periodic recertification | Agents and tool integrations are non-human identities with an owner, least privilege and short-lived credentials |
| Repository conventions | Code, tests and pipeline definitions | Prompts, skills and context packs live beside the code they serve, with owners and review rules |
| Docs-as-code | Documentation written for people | Architecture decisions, standards and glossaries curated as context products that people and AI both consume |
Assess every AI tool before use on data residency, retention periods, whether inputs or outputs are used for training, enterprise administration, audit logs that can be exported, and integration with the organisation's identity provider and access control. Require portability: prompts, context and configuration in open formats, and a documented exit plan stating how the tool would be replaced. A tool without an exit plan is a lock-in decision, taken by default. See Governed openness.
Keep one catalogue of approved tools, each with the highest risk tier of work it may support and the data classifications it may receive. A general-purpose assistant might be approved for low-tier drafting only; a coding assistant with enterprise controls for medium- and high-tier work under review; nothing for critical work beyond analysis. The catalogue is a guardrail: requests outside it go through selection, not around it.
Connect tools and agents to repositories, trackers and data sources through open protocols such as the Model Context Protocol (MCP), routed through an allow-list or gateway rather than ad hoc connections from individual machines. Each integration is registered with an owner, the systems it reaches, the actions it may take and the tier it serves. The gateway logs every call, which gives the audit trail and the kill switch in one place.
Every agent, automation and tool integration gets its own identity: never a person's credentials, never a shared account. It holds the least privilege its task needs, uses short-lived credentials issued at run time, has a named human owner and is recertified on the same cycle as privileged human access. When the agent or integration is retired, its identity is revoked and its secrets destroyed. These identities belong in the element register.
Prompts, skills and context packs are versioned in repositories, changed by pull request, reviewed and owned. When one changes, its evals run in the pipeline, because a one-line prompt change can alter every output that depends on it. Provenance records which version of which context produced an AI-assisted change. See Context is an asset.
Data classification decides what may enter a prompt or context pack: no secrets, credentials or personal data, and nothing above the classification the tool is approved for. Secret scanning and classification checks run before commit and at the gateway. Beyond hygiene, curate shared context products (architecture decisions, coding standards, domain glossaries, approved patterns) with owners and review dates, so AI output reflects how the organisation actually builds rather than generic defaults.
| Tier | Prevent (Guardrails) | Prove (Audit Trail) | Detect (Self-Monitoring) |
|---|---|---|---|
| Low | Catalogue tools only; secret and classification checks on context | Tool and context version recorded in provenance | Usage outside the catalogue; stale context assets |
| Medium | Integrations via the allow-list only; context changes reviewed by their owner; evals run on change | Context repository history links each change to its review and eval result | Eval regressions after context changes; gateway calls outside declared scope |
| High | Tools approved for high tier and the data classification involved; read-only integrations unless a specialist approves write access; short-lived credentials only | Gateway logs retained with the evidence bundle; non-human identities recertified with evidence | Alerts on privilege use, credential age and unusual integration activity |
| Critical | No agent or integration holds write access to critical systems; AI tools may analyse copies only | Documented rationale for any AI tool used; second-line sign-off on context and access | Any attempt by an agent to reach a critical system triggers an incident |
ISO/IEC 42001 expects documented information on the AI management system (clause 7.5) and operational control over AI use (clause 8); the tool catalogue, the integration register and versioned context repositories provide both. The EU AI Act's AI literacy duty (Art. 4) applies to staff using these tools: the catalogue's tiers of permitted use and data rules are part of what they need to know.