GCRI · Foundry
Agents and automation
AI agents can draft analyses, run pipelines and query data at a speed no team can match, which is why their authority must be explicit. An agent that can call tools can call the wrong one, read data it should not, follow instructions planted in a document, or present a draft as reviewed evidence. This page sets out how agent risk develops and spreads, how agents are evaluated before they receive authority, and the controls that let people stop them.
Agents and automation on the record.
Agents and automation: how the risk develops.
AI tools, authority and risk controls. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Tool reach multiplies impact
Each tool an agent can call adds a path from a model error to a real effect: a query, a write, a message, a run. Risk grows with the number of tools and the privileges behind them, not with the model alone.
Instructions arrive in data
Text retrieved from a web page, a document or a dataset can carry instructions the agent then follows. Prompt injection turns ordinary content into a control channel, so tool permissions must never depend on the agent recognising it.
Fluent error looks like evidence
Language models produce confident, well-formatted output that can be wrong, including invented citations and figures. Once an unlabelled draft enters a report, it borrows the authority of the report and the people who signed it.
Automation chains
One agent’s output becomes another’s input, or triggers a pipeline, with no person in between. An early error is copied, transformed and amplified along the chain, and the receipt trail is the only way back to where it started.
Workspace and job console.
The screen a team would use to follow this subject: its measures, states and decisions. Names are examples and values are illustrative.
Workspace and job console
Agents and automation · Project space 12 · Cluster east
- Jobs running31Active
- Queue wait, p508minNormal
- Runs today35924
- Quota used, % this month64Watch
Jobs
| J-86161 | Flood model ensemble | Project owner | 00:37:12 | Running |
| J-42787 | Tile render, zoom 0 to 12 | GIS workspace | 00:02:40 | Running |
| J-76872 | Evidence export | Model steward | 00:00:47 | Done |
| J-55145 | Agent tool call batch | Agent sandbox | 00:01:16 | Policy block |
Policy events
- 10:25GateAgent call needs human approval
- 10:51InfoRun record sealed
- 11:34WarnQuota at 80 pct for project
Automation in Foundry is designed to keep humans in charge in every domain.
- WaterIn practiceAutomated data checks flag anomalies for people to review.What a reader can checkReview logs
- EnergyIn practiceNo automated action touches a real system.What a reader can checkAction boundaries
- HealthIn practiceAgents never access personal health data without basis.What a reader can checkAccess logs
Agent governance follows ISO/IEC 42001 and NIST’s AI RMF; agents and models carry NS-12 cards under the proposed Nexus Standards. Findings go to the Exponential Technology series.
- Security and safety reviews.
- Oversight design proposals.
How agents and automation is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
Model, equations and assumptions
The model structure used for agents and automation, the assumptions it makes and how each is tested.
Ri = f(Hi, Ei, Vi, Ci)hazard, exposure, vulnerability and coping capacityEAL = ∑k pk · Lkover events k with annual probability pkxt+1 = A xt + B ut + εtA carries the couplings, u the shock, ε the error| Assumption | Why it is made | How it is tested |
|---|---|---|
| Hazard and exposure are independent within an event | Keeps the loss integral tractable | Compare with a copula fit on joint records |
| Couplings are linear near the operating point | Lets shocks propagate through A | Perturb beyond the linear range and compare |
| Vulnerability curves transfer between places | Local curves are rarely available | Validate against observed losses where they exist |
- Inputs
- versioned datasets with provenance
- Outputs
- distributions, never single numbers
- Code
- released with the model card and tests
- Reproduction
- same data, code, environment and seed
What is measured, and how well.
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Active agents with a current authority record | proportion of active agents | weekly | Authority register | DECLARED |
| Tool calls denied at the policy gate | count per agent per period | daily | Policy gate logs | OBSERVED |
| Time from kill-switch activation to halt | seconds | per drill or event | Gate and runtime logs | OBSERVED |
| Agent outputs accepted after human review | proportion of outputs | monthly | Review records | OBSERVED |
| Red-team findings open at promotion | count by severity | per model version | Evaluation records | REPORTED |
| Unsupported claims found in sampled outputs | count per sample | monthly | Reviewer audit | OBSERVED |
| Agent actions with a complete receipt | proportion of actions | daily | Receipt store | OBSERVED |
Where the evidence comes from.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| AI Incident Database | Documented real-world AI failures and harms for hazard identification | Open, terms of the database |
| OECD AI Incidents Monitor | Reported AI incidents and hazards drawn from news sources | Terms of the OECD |
| MITRE ATLAS | Adversary tactics and techniques against AI systems | Free, terms of use |
| OWASP Top 10 for large language model applications | Common vulnerability classes in language model and agent systems | CC BY-SA |
| NIST AI RMF Playbook | Suggested actions for the govern, map, measure and manage functions | Public domain |
| Model cards published with open models | Intended use, evaluation and known limits of a base model | Licence per model |
Who decides, and what the evidence serves.
Foundry prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Supervising institutions | Whether an agent may act in their project, with which tools and on which data | Authority record, evaluation record, open red-team findings |
| Data owners | Whether their data may be read by agents or used to train or tune models | Data classes in scope; the recorded training decision |
| Reviewers | Whether an agent’s draft may be accepted into evidence or a report | Receipts, sources cited and checked, evidence labels |
| AI governance leads and data protection authorities | Whether automated processing meets applicable law and the institution’s AI policy | Impact assessment, logs, the human oversight record |
Outputs this topic produces
- Authority records per agent: purpose, tools, data classes, budget, kill-switch and supervisor
- Evaluation and red-team records at each promotion
- Receipts for every agent action
- Labelled drafts that remain assertions until a person reviews them
What AI and safety engineers ask.
- What exactly is this agent permitted to do, on which data, in which project?
- How was the agent and its model evaluated for this use, and by whom?
- Can every agent action be attributed to an identity, a configuration and a supervising institution?
- How quickly can a person stop it, and is that stop enforced outside the agent?
Authority records, gates and receipts.
In the design of the NXS-NSF (trust, authorisation and assurance) Sovereignty Framework (NXS-NSF), every agent and tool holds an authority record that states its purpose, the tools it may call, the data classes it may touch, its rate limits and its kill-switch. Requests without an explicit policy decision fail closed. Agent actions pass the same policy gates and receive the same receipts as human actions, and scopes and kill-switches are enforced at the gate rather than left to the agent’s own configuration.
In NXS-LAB (research, experiments and simulations), agents may run analyses and draft artefacts, but each action is bound to an agent identity, model, tool set, budget and supervising institution, and remains an assertion until a person reviews it. In NXS-STU (composition, dashboards and workflows), agent behaviour inside a composition is declared with its purpose, tools and scope.
Evaluation comes before authority.
- 01
Contract testing
Integrations and agents are tested against their declared contracts before they receive authority in any tenant.
- 02
Model evaluation
Promotion of a model requires evaluation records, including red-team results where the use calls for them.
- 03
Data use
No tenant data is used for training without a recorded decision by the data owner.
- 04
Known limits
Evaluations sample behaviour and cannot exclude every failure; language models can produce fluent, wrong output; and tool-use risks grow with the number of tools an agent can reach. Narrow scopes and human review are the main mitigations.
Agents never take a decision that belongs to an institution or a competent authority, issue a warning, release funds, dispatch resources, sign an acceptance or present a draft as reviewed evidence.
How it is studied, and what the methods cannot say.
- 01Artificial intelligence and machine learningEarth observation models with spatial validation · Model cards and promotion recordsApplied here
- 02Software and safety-critical systems engineeringFail-closed policy gates · Build provenance and bills of materials · Assurance casesApplied here
- 03Systems engineeringCanonical system inventory · Contract-first interfaces · Requirements traced to evidenceApplied here
- 04Data engineering, interoperability and stewardshipValidation at the ingest boundary · Frozen data cuts for reproducible productsApplied here
Where this page’s references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
Who is accountable for an agent’s output?
Why are permissions enforced outside the agent?
Is project data used to train models?
Can I connect my own agent?
Contribute evidence from this page.
Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.