Your AI controls must operate at machine speed

1. AI Security: Agent vulnerabilities enter the development pipeline

Verified development · 28 October 2026

GitHub released code scanning for AI applications in public preview.

The capability automatically scans pull requests for AI-specific risks, including indirect prompt injection, sensitive-information disclosure and excessive agency. GitHub says it can identify paths where untrusted content reaches a model that also has access to tools, data or business systems, and provide mitigation guidance before code is merged.

The preview is available on GitHub.com for eligible repositories with GitHub Advanced Security. It is not currently available on GitHub Enterprise Server.

Read GitHub’s announcement →

Analysis

This is an important sign that agent security is becoming part of secure software development—not a review performed only after an AI application is deployed.

However, an automated alert does not establish that an agent is safe. It may identify a risky code path without understanding every business consequence, external integration or runtime permission. As a public-preview capability, its coverage should also be treated as evolving.

Practical implication

AI security reviews should be integrated into code changes, while runtime controls remain independently governed.

A code scanner may detect that untrusted content can influence an agent. It cannot, by itself, decide whether the agent should have access to a payment system, citizen record, production database or external communication channel.

Action this week

Run a controlled pilot on one agent-enabled repository:

• Enable scanning on a non-critical project.
• Seed test scenarios for prompt injection and excessive permissions.
• Assign an owner to validate and classify alerts.
• Record false positives and missed scenarios.
• Require review before accepting suggested mitigations.
• Confirm that runtime permissions and monitoring are assessed separately.

The output should become evidence in the AI system’s security assessment—not a replacement for it.

2. AI Governance: Behavioural specifications are becoming governance artefacts

Verified development · 29 October 2026

OpenAI published an updated Model Spec—its public description of the behaviour it wants its models to exhibit.

The revision organises its guidance around five values: faithfulness to human intent, harm minimisation, honesty and transparency, human agency, and care. It also adds or expands guidance concerning context, oversight, agency, instruction conflicts and the communication of side effects.

OpenAI explicitly states that the specification describes behaviour it is working towards and that its models do not yet fully reflect it.

Read the updated Model Spec announcement →

Analysis

A provider’s behavioural specification is useful governance evidence because it reveals the intended instruction hierarchy, boundaries and behavioural defaults behind a model.

But it is neither a regulatory standard nor proof of consistent model behaviour. An organisation still needs to test whether the model’s observable behaviour aligns with its own policies, risk appetite and intended use.

There may also be legitimate differences between a provider’s values and an organisation’s obligations—for example, around professional duties, public-sector neutrality, records management or decisions affecting fundamental rights.

Practical implication

Supplier behavioural policies should be incorporated into model due diligence and change management.

A model update is not the only change worth monitoring. A revised behavioural specification, system instruction or safety policy may affect how an AI system interprets ambiguity, manages conflicting requests or acts when instructions are incomplete.

Action this week

Choose one material AI use case and compare the provider’s published behaviour specification with your own requirements:

1. Which instructions take priority?
2. When must the system stop and request human approval?
3. Which assumptions must it disclose?
4. How should it communicate uncertainty and side effects?
5. What actions are prohibited even when requested?
6. How will you test whether actual behaviour matches the specification?

Convert the answers into repeatable test cases. Retest them after material model, configuration or provider-policy changes.

3. Models: Lower-cost computer use expands both opportunity and exposure

Verified development · 26 October 2026

OpenAI released GPT‑6.1 Terra for ChatGPT Work, Codex and the API. The company describes it as a faster, lower-cost model designed for visual reasoning, writing and computer-use tasks such as interpreting documents, completing forms and interacting with software.

OpenAI’s published evaluations report improved computer-use, factuality and coding performance compared with GPT‑5.6 Terra. These are provider-reported results and may not represent performance in a customer’s environment.

The accompanying system-card addendum classifies Terra as Critical for cybersecurity capability and High for biological and chemical capability under OpenAI’s own Preparedness Framework. These are OpenAI classifications, not regulatory risk categories.

OpenAI’s release notes also state that Terra does not support UAE inference residency; the restriction concerns where inference occurs, rather than the user’s physical location.

Read the GPT‑6.1 Terra announcement →
Review the system-card addendum →
Read the model release notes →

Analysis

Lower cost can change an AI system’s risk profile because it makes high-volume automation commercially viable. A model that was previously used occasionally for assistance may now be considered for continuous document processing or computer-based action.

That transition—from advising a user to performing an action—should trigger reassessment.

For UAE organisations, product availability should not be confused with data-residency suitability. Residency, retention, access and cross-border processing need to be confirmed for the exact product surface and contract.

Practical implication

Model selection should consider the complete deployment architecture, not performance and token cost alone.

Computer-use models require particular attention to tool permissions, transaction limits, sensitive information displayed on screen, confirmation requirements and recovery when an action fails midway.

Action this week

Before approving a computer-use pilot, document:

• The exact model and product surface
• Where inference and data processing occur
• Applications and data the model can access
• Actions requiring human confirmation
• Transaction, time and volume limits
• Logging and screen-action traceability
• Representative task and failure testing
• The kill switch and accountable operator

Benchmark the system on your actual workflow rather than relying solely on the provider’s evaluation results.

Editorial viewpoint

AI governance is entering a more operational phase. The important question is no longer only whether an organisation has approved an AI system. It is whether controls remain effective while that system reads untrusted content, interprets incomplete instructions and takes action across business applications.

My proposed focus for leaders is governance at the point of action: testable behavioural expectations, least-privilege access, continuous monitoring and a clear route for human intervention. Faster and more affordable AI should enable greater value—but also faster evidence and accountability.

This week’s checklist: Before an AI system can act

Select one agent or computer-use workflow and confirm:

• Purpose: Its permitted task and prohibited uses are documented.
• Identity: The model, version, product surface and provider are recorded.
• Data: Processing location, retention and sensitive-data boundaries are known.
• Access: Tools and permissions are limited to what the task requires.
• Confirmation: High-impact actions require appropriate human approval.
• Testing: Prompt injection, ambiguity and partial-failure scenarios are evaluated.
• Monitoring: Actions, alerts and overrides are recorded and reviewed.
• Response: A named owner can pause, investigate and safely restart the system.

Any answer based on assumption rather than evidence should become a remediation item.