Contractor Access Segregation Governance

2. Summary

Contractor Access Segregation Governance requires that organisations deploying AI agents enforce strict, enforceable boundaries on the access granted to third-party human personnel — contractors, consultants, outsourced operations staff, vendor engineers, and any individual who is not a direct employee — to the systems, data, training artefacts, model weights, configuration, and governance controls that constitute the AI agent deployment. Contractors represent a distinct threat model from employees: they typically serve multiple clients, their background verification is less rigorous, their tenure is shorter and less predictable, their loyalties are divided, their access needs are narrower than the broad access often granted, and their departure from the organisation occurs without the structured offboarding processes applied to employees. This dimension mandates that contractor access is segregated by design — scoped to the minimum required, technically enforced rather than policy-dependent, continuously monitored, and automatically revoked when no longer justified.

3. Example

Scenario A — Contractor Retains Broad Access After Engagement Ends: A financial services firm engages a machine learning consultancy to fine-tune a customer credit scoring agent. The consultancy deploys three engineers who are provisioned with access to the model training environment, the training dataset (containing 2.4 million customer credit records), the model registry, the inference configuration, and the production monitoring dashboard. The engagement runs for 4 months and concludes. The firm's HR system records the end of the consulting engagement, but no automated process links HR termination records to infrastructure access provisioning. Two of the three contractor accounts are manually deactivated by an IT administrator who sees the email notification. The third account — belonging to the lead consultant — is missed because the administrator is on leave the day the notification arrives. The account remains active for 11 months. During that period, the former consultant's credentials are compromised through a phishing attack against the consultancy (which is breached independently). The attacker uses the still-active credentials to access the training environment, exfiltrate the credit scoring model weights and 340,000 customer records, and modify the model's fairness calibration parameters.

What went wrong: Contractor access was provisioned through the same manual process as employee access, with no segregation or automated lifecycle management. No technical control linked access expiry to engagement end dates. The manual deactivation process had a single point of failure (one administrator). The contractor's access scope was broader than necessary — the lead consultant did not need ongoing production monitoring access after the initial deployment. Consequence: 340,000 customer records exfiltrated, model integrity compromised, FCA enforcement action for inadequate third-party access controls, £3.2 million in remediation including model retraining, customer notification, and credit monitoring services, and 14-month regulatory consent order.

Scenario B — Contractor Accesses Training Data Beyond Scope: A government agency contracts a data annotation firm to label training data for a benefits eligibility agent. The annotation firm's 12 annotators are granted access to the annotation platform, which draws data from the agency's citizen records database. The annotation scope covers 50,000 records selected for labelling. However, the annotation platform's access control grants the annotators read access to the full database view rather than a filtered view containing only the 50,000 in-scope records. Over 6 months, one annotator — curious about a personal acquaintance — queries the database and views 47 records outside the annotation scope, including sensitive health and income data. The access is discovered during a quarterly access review when audit logs reveal queries outside the expected record set.

What went wrong: The contractor's data access was not segregated to the minimum scope. The annotation platform granted access to the full database rather than an isolated, filtered dataset containing only the records required for the task. No technical control prevented queries outside the annotation scope. The 6-month detection delay meant the inappropriate access occurred over multiple sessions without alert. Consequence: Breach of citizen data requiring notification under the Data Protection Act, parliamentary question about government data handling practices, suspension of the annotation contract, 4-month delay to the agent deployment programme, and £420,000 in remediation costs.

Scenario C — Vendor Engineer Modifies Production Agent Configuration: An enterprise deploys a customer-facing agent for product recommendations. The agent's infrastructure is managed by a cloud platform vendor whose support engineers have access to the platform's configuration layer for troubleshooting. During a support ticket investigation, a vendor engineer modifies the agent's inference temperature parameter from 0.3 to 0.9 to "test whether the issue is related to generation settings." The change is made in the production environment rather than a staging environment because the vendor's access does not distinguish between environments. The higher temperature causes the agent to generate highly variable, occasionally incoherent product recommendations for 8 hours before the organisation's monitoring detects the quality degradation. During that period, 4,200 customers receive poor recommendations, 380 customer complaints are filed, and 94 customers abandon their purchases.

What went wrong: The vendor engineer had undifferentiated access to both staging and production environments. No technical control prevented configuration changes in production by third-party personnel. No approval workflow required organisational sign-off before vendor personnel modified production configuration. The vendor's access was not segregated to read-only diagnostic access — the troubleshooting ticket did not require write access. Consequence: 8 hours of degraded customer experience, 380 complaints, £67,000 in estimated lost revenue, and customer trust erosion.

4. Requirement Statement

Scope: This dimension applies to every AI agent deployment where any third-party human personnel — contractors, consultants, outsourced staff, vendor support engineers, managed service provider staff, or any individual who is not a direct employee of the deploying organisation — has or may have access to any component of the agent's technology stack, data, models, configuration, governance artefacts, or operational environment. The scope covers access to: training and evaluation data, model artefacts (weights, adapters, tokenizers, embeddings), inference configuration (parameters, prompts, guardrails), production infrastructure (compute, storage, networking), monitoring and observability systems, governance and compliance records, and administrative controls (identity management, access control configuration, deployment pipelines). The scope extends to both direct access (logging into systems) and indirect access (accessing data through APIs, annotation platforms, or managed service interfaces that do not require direct system login). Organisations using fully managed AI services remain in scope — the managed service provider's personnel access to the organisation's data and configuration must be governed.

4.1. A conforming system MUST maintain a registry of all third-party personnel with access to any component of the AI agent deployment, recording for each individual: their identity, employing organisation, engagement scope, authorised access boundaries, access start date, planned access end date, and the business justification for their access.

4.2. A conforming system MUST enforce contractor access boundaries through technical controls — network segmentation, role-based access control with contractor-specific roles, data view filtering, or environment isolation — rather than relying solely on contractual obligations or policy agreements.

4.3. A conforming system MUST scope contractor access to the minimum necessary for the specific engagement task, applying the principle of least privilege such that a contractor engaged for model training does not receive access to production inference, a contractor engaged for data annotation does not receive access to the full dataset beyond the annotation scope, and a contractor engaged for infrastructure support does not receive write access to model or configuration artefacts.

4.4. A conforming system MUST implement automatic access expiration tied to the engagement end date, with no mechanism for contractor access to persist beyond the engagement period without explicit re-authorisation by an accountable internal owner.

4.5. A conforming system MUST segregate contractor access from employee access in audit logs, enabling distinct monitoring, alerting, and review of contractor activity without commingling it with employee activity.

4.6. A conforming system MUST require explicit approval from an internal accountable owner before any contractor account is granted write access to production systems, model artefacts, agent configuration, or training data, with the approval recorded and retained.

4.7. A conforming system MUST conduct access reviews for all active contractor accounts at intervals not exceeding 90 days, verifying that each account's access scope remains necessary and proportionate to the current engagement.

4.8. A conforming system SHOULD implement environment segregation that prevents contractor access to production environments unless a specific, time-bounded, and approved production access request has been granted — default contractor access should be limited to non-production environments.

4.9. A conforming system SHOULD implement data masking or synthetic data substitution for contractor-accessible environments, ensuring that contractors working on development, testing, or annotation tasks do not require access to real production data containing personal or sensitive information.

4.10. A conforming system SHOULD implement session recording or enhanced logging for contractor access sessions, capturing commands executed, data accessed, and configuration changes made, with retention sufficient for forensic investigation.

4.11. A conforming system MAY implement just-in-time access provisioning for contractors, where access is granted only for the duration of a specific task (measured in hours, not months) and automatically revoked upon task completion or time expiry.

5. Rationale

Third-party human personnel represent a distinct and elevated risk vector for AI agent deployments compared to direct employees. This is not a statement about the trustworthiness of individual contractors — it is a structural observation about the risk characteristics of the relationship. Contractors operate under a different incentive structure (loyalty to their employer, not the client), are subject to different vetting processes (the client organisation typically relies on the contractor's employer for background checks), have shorter tenure (engagement-length rather than employment-length), serve multiple clients simultaneously (creating cross-contamination risks), and leave without the structured offboarding process that organisations apply to departing employees. Each of these structural factors increases the probability that access granted to a contractor will be excessive, improperly monitored, or improperly revoked.

The AI agent context amplifies these risks in three ways. First, AI systems concentrate sensitive data: a training dataset for a credit scoring agent contains millions of financial records; an annotation dataset for a medical agent contains patient records; a training pipeline for a customer agent contains behavioural data. Contractor access to these datasets — even for a legitimate purpose — creates a large blast radius if that access is compromised or misused. Second, AI systems contain high-value intellectual property: model weights, training methodologies, prompt engineering strategies, and fine-tuning data represent significant competitive value. Contractor access to these artefacts creates exfiltration risk that does not exist for traditional transactional systems. Third, AI system configuration has operational leverage: a single configuration change (Scenario C) can affect thousands or millions of user interactions. Contractor write access to configuration multiplies the blast radius of a single improper action.

Regulatory frameworks increasingly recognise third-party access as a first-class risk category. DORA Article 28 mandates that financial entities manage risks from ICT third-party service providers, which includes the personnel those providers deploy. The FCA's Senior Managers and Certification Regime (SM&CR) holds senior managers personally accountable for the actions of third parties operating within their area of responsibility. The GDPR's processor provisions (Articles 28-29) require data controllers to impose contractual and technical controls on processors, including their staff. The EU AI Act's requirements for human oversight (Article 14) and robustness (Article 15) are undermined if third-party personnel can modify AI system behaviour without adequate controls. ISO 27001 Annex A includes controls specifically for supplier relationships and access management. Across all regulatory frameworks, the expectation is clear: organisations must technically enforce — not merely contractually require — access segregation for third-party personnel.

The consequence of inadequate contractor access segregation is compounded by the detection challenge. Contractor misuse or compromise is typically harder to detect than employee misuse because: contractor activity patterns are less well-understood (making anomaly detection less effective), contractor accounts may be shared or generic (making attribution difficult), and contractor access is often provisioned through exception processes that bypass standard monitoring. By the time a contractor access incident is detected, the damage has typically been accumulating for weeks or months (11 months in Scenario A, 6 months in Scenario B). AG-492 addresses this by requiring both preventive controls (segregation, least privilege, technical enforcement) and detective controls (segregated audit logs, 90-day reviews, enhanced monitoring).

6. Implementation Guidance

Contractor Access Segregation Governance requires a layered approach combining identity management, technical access controls, data isolation, monitoring, and lifecycle automation. The fundamental principle is that contractor access must be technically constrained, not trust-dependent — the system architecture should make it impossible for a contractor to exceed their authorised scope, rather than relying on the contractor's judgement or goodwill to stay within bounds.

Recommended patterns:

• Contractor-specific identity tier. Create a distinct identity tier for contractor accounts in the identity management system — separate from employee accounts and service accounts. Contractor accounts should have a visually distinct naming convention (e.g., "ext-" prefix), a mandatory expiration date that cannot exceed the engagement end date, and a mandatory internal sponsor who is accountable for the account's existence and scope. The contractor tier should have different default permissions (more restrictive), different monitoring thresholds (more sensitive), and different review cadences (more frequent) than employee accounts.
• Engagement-scoped access bundles. Rather than granting individual permissions to each contractor, define engagement-scoped access bundles — pre-configured sets of permissions tailored to common contractor engagement types. Examples: "Model Training — Read/Write Training Environment, Read Training Data (filtered), No Production Access," "Data Annotation — Read Annotation Platform, Read Annotation Dataset (filtered), No Model Access, No Infrastructure Access," "Infrastructure Support — Read/Write Non-Production Infrastructure, Read-Only Production Infrastructure, No Data or Model Access." These bundles enforce least privilege by design and eliminate the ad-hoc permission accumulation that leads to excessive access.
• Automated lifecycle management tied to HR/procurement systems. Integrate contractor access provisioning with the procurement or vendor management system so that access is automatically provisioned when an engagement begins and automatically revoked when the engagement ends. The integration must be bidirectional: when HR records an engagement end date, the access system sets a hard expiration. If the engagement is extended, the access expiration is extended — but only through an explicit re-authorisation workflow, not through indefinite persistence. This eliminates the manual deactivation failure in Scenario A.
• Data view isolation for annotation and training tasks. When contractors require access to data for annotation, labelling, evaluation, or training purposes, provide access through isolated data views that contain only the records in scope for the engagement. The annotation platform or training environment should query a filtered view, not the source database. The filter should be enforced at the data layer (database view, API filter, or data export), not at the application layer (which can be bypassed). This eliminates the full-database access in Scenario B.
• Environment segregation with explicit production access requests. By default, contractor accounts should have no access to production environments. When production access is required (e.g., for incident diagnosis), implement a time-bounded access request workflow: the contractor requests production access for a specific purpose and duration (e.g., "read-only access to production logs for ticket #12345, 4 hours"), an internal approver grants the request, access is provisioned with automatic expiry at the approved duration, and all actions during the production access session are recorded. This eliminates the undifferentiated environment access in Scenario C.
• Segregated audit log streams. Route contractor access events to a dedicated audit log stream that is monitored with contractor-specific alert rules. Contractor alerts should have lower thresholds than employee alerts — for example, alert on any contractor query that returns more than 1,000 records (which may be normal for employees but unusual for contractors), any contractor access outside business hours, or any contractor attempt to access resources outside their engagement scope.

Anti-patterns to avoid:

• Shared contractor accounts. Providing a single account shared by multiple contractor personnel. Shared accounts make attribution impossible, prevent individual access revocation, and violate the principle of individual accountability. Every contractor must have a unique, individually identifiable account.
• Cloned employee permissions. Provisioning a contractor by cloning the permissions of a similar employee role. Employee roles accumulate permissions over time and typically have far broader access than any single contractor engagement requires. Cloning creates excessive access by default.
• Contract-only enforcement. Relying on the consulting agreement's confidentiality and data handling clauses to constrain contractor behaviour without implementing technical controls. Contractual obligations are detective (you can sue after the fact) and deterrent, not preventive. Technical controls prevent the misuse from occurring.
• Indefinite contractor accounts. Provisioning contractor accounts without expiration dates, relying on manual deactivation when the engagement ends. Manual deactivation has a high failure rate, as demonstrated in Scenario A. Every contractor account must have an automatic expiration.
• Commingled audit logs. Logging contractor and employee activity in the same stream with the same alert thresholds. Contractor activity patterns differ from employee patterns, and contractor-specific anomalies will be lost in the volume of employee activity if they are not segregated.

Industry Considerations

Financial Services. Financial institutions face the most stringent regulatory expectations for third-party access controls. DORA, FCA SYSC, PRA supervisory statements, and SOX all impose requirements on third-party access governance. Financial institutions should implement all SHOULD requirements as MUST, including environment segregation (4.8), data masking (4.9), and session recording (4.10). The financial impact of contractor access incidents (Scenario A: £3.2 million) reflects the high value and sensitivity of financial data. Institutions should also consider contractual requirements that mandate the contractor's employer implement complementary controls (e.g., device management, background screening).

Healthcare. Clinical data is among the most sensitive data categories, and healthcare regulations (HIPAA, GDPR health data provisions, NHS DSPT) impose specific requirements on access to patient data by third parties. The data view isolation pattern is essential — contractors working on medical AI must never have access to patient records beyond their defined scope. Synthetic data substitution (Requirement 4.9) is particularly valuable in healthcare, where synthetic patient records can support development and testing without exposing real patient data.

Public Sector. Government agencies face additional constraints including security clearance requirements for access to certain data categories, procurement regulations that mandate specific third-party access controls, and public accountability requirements that make data breaches involving citizen data politically damaging (Scenario B). Agencies should implement security classification-aligned access tiers that automatically restrict contractor access based on data classification per AG-014.

Crypto/Web3. Contractor access to cryptographic key material, wallet infrastructure, and smart contract deployment pipelines presents extreme risk — a contractor with write access to a wallet or deployment pipeline could execute irreversible transactions. Just-in-time access provisioning (Requirement 4.11) is essential for crypto deployments, and production write access should require multi-party approval with at least two internal signatories.

Maturity Model

Basic Implementation — The organisation maintains a registry of all contractor accounts with engagement scope, sponsoring owner, and expiration dates. Contractor accounts use a distinct identity tier with a naming convention that distinguishes them from employee accounts. Access is scoped to the engagement through engagement-specific access bundles. Automatic expiration is enforced — accounts cannot persist beyond the engagement end date without re-authorisation. Write access to production requires documented approval. Access reviews are conducted at least every 90 days. This level meets the minimum mandatory requirements of 4.1 through 4.7.

Intermediate Implementation — All basic capabilities plus: environment segregation prevents default contractor access to production environments, with a time-bounded access request workflow for necessary production access. Data masking or synthetic data substitution is implemented for development, testing, and annotation environments. Contractor audit logs are segregated from employee logs with contractor-specific alerting rules. Lifecycle management is automated through integration with the procurement or vendor management system. Access reviews are enhanced with automated anomaly detection that flags unusual contractor activity patterns.

Advanced Implementation — All intermediate capabilities plus: just-in-time access provisioning grants contractor access only for the duration of specific tasks with automatic revocation. Session recording captures full command-level detail for contractor access sessions. Real-time monitoring detects contractor access anomalies (scope violations, unusual query patterns, off-hours access) and triggers immediate alerts. Cross-engagement analysis detects contractors who accumulate access across multiple engagements, creating a composite access scope that exceeds any individual engagement's justification. The organisation can demonstrate through penetration testing that no contractor account can exceed its defined access boundaries.

7. Evidence Requirements

Required artefacts:

• Contractor access registry. Current registry of all active contractor accounts showing identity, employing organisation, engagement scope, authorised access boundaries, access start date, planned end date, internal sponsor, and business justification.
• Access provisioning and deactivation records. Logs of all contractor account provisioning events (with approval records) and deactivation events (with verification of completeness).
• Technical access control configuration. Documentation of the technical controls enforcing contractor access boundaries — role definitions, network segmentation rules, data view configurations, and environment isolation mechanisms.
• Production write access approvals. Individual approval records for each instance of contractor write access to production systems, model artefacts, or configuration, showing the approver, the scope, and the duration.
• Access review records. Records of quarterly (or more frequent) access reviews, showing each contractor account reviewed, the access scope verified, any changes made, and the reviewer identity.
• Contractor audit log samples. Samples of segregated contractor audit logs demonstrating that contractor activity is distinctly logged and monitored.
• Lifecycle automation evidence. Where automated lifecycle management is implemented, evidence of the integration between HR/procurement systems and the access provisioning system, including test results demonstrating automatic deactivation.

Retention requirements:

• Contractor access registry and provisioning records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Audit log samples and access review records: minimum 5 years for regulated sectors; minimum 3 years otherwise.
• Production write access approvals: retained for the full duration of the engagement plus 3 years after the engagement ends.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Registry and provisioning records must be queryable — an auditor must be able to request "show me all contractor access active on date X" and receive a definitive answer. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Test 8.1: Contractor Access Registry Completeness

• Stimulus: Independently enumerate all non-employee accounts with access to any AI agent system component (through identity provider reports, access control lists, and infrastructure audit). Compare the enumerated accounts against the contractor access registry.
• Expected behaviour: Every non-employee account with access appears in the contractor access registry with complete metadata (identity, employer, engagement scope, access boundaries, dates, sponsor).
• Pass criteria: 100% of non-employee accounts with access are registered. Zero unregistered contractor accounts.
• Fail criteria: Any non-employee account with access is absent from the registry, or any registered account has incomplete metadata (missing sponsor, missing end date, missing scope definition).

Test 8.2: Technical Access Boundary Enforcement

• Stimulus: For 3 contractor accounts with different engagement scopes, attempt to access resources outside the defined scope: (a) a training-scoped contractor attempts to access production inference, (b) an annotation-scoped contractor attempts to query records outside the annotation dataset, (c) an infrastructure-scoped contractor attempts to read model artefacts.
• Expected behaviour: All out-of-scope access attempts are denied by technical controls (not just policy).
• Pass criteria: All 3 out-of-scope access attempts are denied at the technical layer (access control, network rule, or data view filter). Denial is logged and attributed.
• Fail criteria: Any out-of-scope access attempt succeeds, or denial occurs through application-layer policy rather than infrastructure-layer technical controls.

Test 8.3: Automatic Access Expiration

• Stimulus: Create a test contractor account with an engagement end date set to a past date (simulating an expired engagement). Verify that the account is deactivated. Then create a test account with an end date 24 hours in the future, wait for expiration, and verify deactivation.
• Expected behaviour: Expired accounts are automatically deactivated. The account cannot authenticate or access any resources after expiration.
• Pass criteria: Both test accounts are deactivated at or before their expiration dates. Authentication attempts after expiration fail. No manual intervention is required for deactivation.
• Fail criteria: Either account remains active after its expiration date, or deactivation requires manual intervention.

Test 8.4: Production Write Access Approval Enforcement

• Stimulus: Attempt two production write operations using contractor credentials: (a) one with a valid, current approval record for the specific operation, and (b) one without any approval record.
• Expected behaviour: Operation (a) succeeds. Operation (b) is denied.
• Pass criteria: The approved operation succeeds and is logged with the approval reference. The unapproved operation is denied with a clear error indicating that production write access requires approval.
• Fail criteria: The unapproved write operation succeeds, or the approved operation is denied.

Test 8.5: Segregated Audit Log Verification

• Stimulus: Execute a defined set of 10 operations using a contractor account and 10 operations using an employee account. Examine the audit log streams. Verify that the contractor operations appear in the contractor-specific audit stream and are distinguishable from employee operations.
• Expected behaviour: Contractor operations are logged in a segregated stream (or are distinctly flagged in a shared stream) with contractor-specific metadata. Alert rules process contractor events separately from employee events.
• Pass criteria: All 10 contractor operations are identifiable in the contractor audit stream. Contractor operations are not commingled with employee operations in a way that prevents contractor-specific analysis or alerting.
• Fail criteria: Any contractor operation cannot be identified as contractor activity in the audit log, or contractor operations cannot be filtered and analysed separately from employee operations.

Test 8.6: Quarterly Access Review Execution

• Stimulus: Request evidence of the most recent access review for all active contractor accounts. Verify that the review was conducted within the last 90 days, that each account was individually assessed, and that any identified excess permissions were remediated.
• Expected behaviour: A documented access review exists within the last 90 days covering all active contractor accounts. Each account has an individual assessment record.
• Pass criteria: The review occurred within 90 days. All active contractor accounts at the time of review were included. Any excess permissions identified during the review were remediated within 14 days.
• Fail criteria: No review exists within 90 days, or any active contractor account was omitted from the review, or identified excess permissions remain unremediated beyond 14 days.

Test 8.7: Least Privilege Verification

• Stimulus: For 5 contractor accounts, compare the granted access scope against the documented engagement scope. Identify any permissions that are not justified by the engagement description — for example, a data annotation contractor with model registry write access, or an infrastructure contractor with training data read access.
• Expected behaviour: Each contractor's granted permissions are a subset of the permissions required for their engagement scope. No excess permissions exist.
• Pass criteria: All 5 contractor accounts have permissions strictly aligned with their engagement scope. Zero unjustified permissions.
• Fail criteria: Any contractor account has permissions that exceed the engagement scope, or any permission cannot be traced to a documented justification.

Conformance Scoring

• Score 0: No contractor access segregation exists. Contractors are provisioned with employee-equivalent access. No contractor registry is maintained. No automatic expiration exists. Contractor activity is not distinctly monitored.
• Score 1: A contractor registry exists but may be incomplete. Contractor accounts are distinguished from employee accounts. Access expiration dates are set but enforcement may be manual. Access reviews occur but may not cover all accounts or may exceed the 90-day cadence. Technical enforcement of access boundaries is partial — some boundaries are policy-dependent rather than technically enforced.
• Score 2: A complete contractor registry is maintained with full metadata. All contractor access boundaries are technically enforced. Automatic expiration is implemented and verified. Production write access requires documented approval. Contractor audit logs are segregated. Access reviews occur at least every 90 days with demonstrated remediation of excess permissions. Least privilege is verified and maintained.
• Score 3: All Score 2 capabilities plus: just-in-time access provisioning is implemented. Session recording captures contractor actions at the command level. Real-time anomaly detection monitors contractor activity with contractor-specific behavioural baselines. Environment segregation prevents default production access. Data masking or synthetic data substitution is implemented for non-production environments. Independent penetration testing confirms that contractor access boundaries cannot be circumvented.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 14 (Human Oversight)	Supports compliance
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Supports compliance
SOX	Section 404 (Internal Controls Over Financial Reporting)	Direct requirement
FCA SYSC	8.1.1R (Outsourcing Requirements)	Direct requirement
NIST AI RMF	GOVERN 1.4, MANAGE 2.3	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks and Opportunities)	Supports compliance
DORA	Article 28 (ICT Third-Party Risk), Article 30 (Key Contractual Provisions)	Direct requirement

EU AI Act — Article 14 (Human Oversight) and Article 15 (Accuracy, Robustness and Cybersecurity)

Article 14 requires that high-risk AI systems can be effectively overseen by natural persons. When contractors can modify agent behaviour (Scenario C), the organisation's human oversight is undermined — the humans overseeing the agent may not be aware that a third party has changed its configuration. Article 15 requires resilience against manipulation, which includes manipulation by authorised third-party personnel with excess access. If a contractor can modify model weights, training data, or inference configuration without appropriate controls, the system's robustness against manipulation is inadequate. AG-492 ensures that third-party access is constrained such that human oversight and system integrity are maintained.

SOX — Section 404 (Internal Controls Over Financial Reporting)

SOX Section 404 requires organisations to maintain effective internal controls over financial reporting, which includes controls over who can modify the systems that produce financial reports or influence financial decisions. A financial-value agent that influences credit decisions, transaction processing, or risk calculations is within SOX scope. Contractor access to these systems must be controlled with the same rigour as employee access — arguably more rigour, given the elevated risk profile. SOX auditors specifically assess whether third-party access to financial systems is appropriately restricted, reviewed, and logged. The contractor access registry (4.1), production write approval (4.6), and quarterly access review (4.7) requirements directly support SOX compliance.

FCA SYSC — 8.1.1R (Outsourcing Requirements)

The FCA requires firms to take reasonable steps to avoid undue additional operational risk when outsourcing functions, including critical functions. SYSC 8.1.1R mandates that firms maintain appropriate controls over outsourced activities. This extends to contractor access to AI agent systems — the FCA expects that firms can demonstrate who has access to their critical systems, that access is proportionate, and that the firm retains control over the outsourced activity. The FCA's operational resilience framework further requires that firms understand their dependency on third parties, including third-party personnel with system access.

NIST AI RMF — GOVERN 1.4, MANAGE 2.3

GOVERN 1.4 addresses organisational policies for AI risk management, including policies governing third-party involvement in AI system development and operation. MANAGE 2.3 addresses the management of AI system access and the control of who can modify AI system behaviour. AG-492 provides the operational implementation of these governance and management functions for the specific risk of contractor access.

DORA — Article 28 (ICT Third-Party Risk) and Article 30 (Key Contractual Provisions)

DORA Article 28 requires financial entities to manage ICT third-party risk, including the risk arising from third-party personnel with access to the entity's ICT systems. Article 30 specifies contractual provisions that must be included in arrangements with ICT third-party providers, including provisions for access control, data security, and audit rights. AG-492's requirements for technical access enforcement (4.2), least privilege (4.3), and segregated monitoring (4.5) provide the operational mechanisms through which DORA's third-party risk management requirements are implemented for AI agent deployments.

ISO 42001 — Clause 6.1 (Actions to Address Risks and Opportunities)

ISO 42001 requires organisations to identify risks to their AI management system and implement treatments. Third-party human access to AI systems is a risk that must be identified and treated. AG-492's comprehensive access controls — registry, technical enforcement, automatic expiration, production approval, and review cadence — constitute a risk treatment plan for the third-party access risk category that ISO 42001 requires organisations to address.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	System-wide — contractor access incidents affect the specific systems to which the contractor has access, but the damage can extend to all downstream systems that depend on the compromised data, model, or configuration; cross-engagement contractors may accumulate access affecting multiple independent systems

Consequence chain: Inadequate contractor access segregation creates a persistent, high-privilege threat vector into the AI agent deployment. The immediate technical failure is excess access — a contractor has broader access than their engagement requires, persisting longer than the engagement justifies, with less monitoring than the risk demands. This excess access enables multiple consequence pathways. In the data exfiltration pathway (Scenario A), a contractor or their compromised credentials are used to extract sensitive data — training data containing customer records, model weights representing significant intellectual property, or governance artefacts revealing the organisation's control posture. In the data leakage pathway (Scenario B), a contractor accesses data beyond their engagement scope, violating privacy regulations and data protection principles. In the operational disruption pathway (Scenario C), a contractor modifies production configuration, model artefacts, or inference parameters, degrading agent performance or introducing unsafe behaviour. The compounding factor is detection latency: contractor access incidents are typically discovered weeks or months after they begin (11 months in Scenario A, 6 months in Scenario B), because contractor activity is not separately monitored and contractor accounts persist without lifecycle governance. The business consequences include regulatory enforcement for third-party access control failures (FCA, DORA, GDPR), financial loss from data breaches and operational disruption, reputational damage from publicised contractor access incidents, and loss of customer and citizen trust when third-party access to their data is revealed to be inadequately controlled. The insidious nature of this failure is that it represents a standing vulnerability — excess contractor access exists continuously, creating a persistent opportunity for exploitation, and the organisation may not know the vulnerability exists until it is exploited.

Cross-references: AG-012 (Credential & Secret Lifecycle Governance), AG-014 (Data Classification Governance), AG-493 (Subprocessor Governance), AG-495 (Procurement Security Requirement Governance), AG-439 (Reviewer Independence Governance), AG-015 (PII & Sensitive Data Handling), AG-010 (Time-Bounded Authority Enforcement), AG-404 (Network Egress and DNS Control Governance).