Platform at AGIACC
The AGIACC Platform
Define what an AI workload may do. Enforce the supported boundaries. Evaluate the result.
We envision a developer platform that makes execution authority explicit, connects it to protection mechanisms, and produces evidence of both protection and useful task performance. Its foundation spans application interfaces, system software and hardware, with efficiency considered throughout.
The first planned release is the AGIACC Reference Platform and SDK: a self-hosted reference environment, developer interfaces and an evaluation kit. Our current foundation is research and technical artifacts; the product capabilities below describe the intended design.
One task, an explicit execution boundary
Review an approved maintenance log
Produce a report for operator review.
1. Specify tool authority
- Inputs
- Approved logs · read only
- Outputs
- Designated report directory · write
- Tool network
- No outbound access
- Equipment control
- No control-service connector
Scope shown for the analysis tool. Model access is configured separately.
2. Run within the configured boundary
Review policy · configure the runtime · invoke the tool
Read approved data analyse write report
Runtime controls enforce supported file and network restrictions.Return the report for operator review.
3. Test expected access decisions
- Read an approved logExpected: Allow
- Write the analysis reportExpected: Allow
- Read data outside the declared scopeExpected: Deny
- Contact an external hostExpected: Deny
4. Inspect the evaluation report
- Task result
- Report and resulting filesystem state
- Protection
- Expected and observed boundary decisions
- Resource cost
- Startup, task latency and peak memory
- Configuration
- Policy, tool, runtime and hardware versions
Built around the engineer’s deployment decision#
Our initial users are platform and security engineers connecting AI agents to sensitive information, executable tools and enterprise services. They need to establish what a workload can access, what happens when it exceeds that authority, and whether the controls preserve the intended task.
The proposed workflow begins with one application and a defined deployment environment. An engineer specifies permitted resources and operations, reviews how those requirements map to the selected backend, and runs legitimate tasks alongside access-violation and fault cases. The resulting report should support a concrete decision: integrate, revise the boundary, or investigate a missing capability.
Enterprise document analysis and software tools provide an accessible starting point. Industrial maintenance, robotics and embedded AI extend the opportunity to device access, timing and recovery, with additional domain requirements to be evaluated in later stages.
Four connected product capabilities#
The product thesis is the connection between requested authority, effective enforcement and reproducible evidence. Existing isolation and hardware mechanisms provide foundations; AGIACC aims to make their application-level meaning and combined costs easier to inspect and evaluate.
Task policy and developer interfaces
Express the authority a task actually needs.
An SDK and CLI for declaring tool access, permitted resource operations and execution limits. Reviewable policies would connect application intent to concrete files, endpoints and supported controls.
Intended outputA versioned task policy and a summary of effective access.
Isolated execution and mediation
Apply policy at the relevant execution boundary.
A runtime integration for isolated tool execution, lifecycle management and structured failures. Service and credential mediation would be added through explicitly scoped, trusted connectors as deployment needs emerge.
Intended outputExecution results linked to supported controls and recorded boundary events.
Evaluation and inspection
Test protection alongside legitimate task performance.
A workbench for running controlled workloads, adversarial inputs and selected fault cases. Independent outcome checks and configuration records would support reproduction and regression analysis.
Intended outputAn evaluation report covering behavior, limitations and measured resource cost.
Hardware and compiler integration
Connect native protection to the software that uses it.
Platform-specific profiles for evaluating memory protection, compartment boundaries and compiler support. Early native-component experiments would inform later processor, accelerator and device co-design.
Intended outputDocumented protection coverage, fault behavior and optimization results for each tested configuration.
Policy administration belongs outside the untrusted workload. The planned interface would reject configurations containing unsupported restrictions before execution and require operator authorization to expand access. A permitted network destination alone does not establish permission for every account, API operation or resource at that destination; service connectors need their own authorization rules.
One platform, from hardware to applications#
The long-term product connects three engineering layers. Each deployment profile would identify the protection mechanisms it supports, its trusted components, compatibility requirements and evaluation results. Shared interfaces should make those differences explicit while preserving a consistent developer workflow.
Target product architecture
Trustworthiness and efficiency across the stackApplication frameworks and services
Task intent → explicit authority
SDKs, tool adapters and application frameworks for integrating permissions and failure handling into AI workflows. Later platform services would support operational review and deployment management.
First planned contributionTask policy, invocation interface and reference application.
System software and runtime
Explicit authority → supported enforcement
Isolation, service mediation, resource management and controlled recovery. The runtime would identify which controls apply and which host components or external services remain trusted.
First planned contributionOne execution backend, structured results and evaluation tooling.
Hardware, chip design and new devices
Hardware properties → enforced system boundaries
Memory-access enforcement, compartmentalization and accelerator or device boundaries, integrated with the necessary compiler and runtime support. New hardware would address limitations demonstrated through the platform.
First planned contributionA separate native-protection experiment on existing hardware or emulation.
Efficiency work will target measured bottlenecks in compilation, isolation, scheduling and memory use. Training and inference workloads provide further opportunities for resource management as the platform develops. Optimizations must preserve the stated protection requirements and be evaluated against a recorded baseline.
The first release: a complete, bounded workflow#
The reference release will concentrate on one documented host configuration and one execution backend. An agent uses an isolated analysis tool to read approved documents or maintenance logs and produce a report for operator review. Tests will attempt unrelated file access and outbound communication. A separate native-component experiment will examine selected memory violations on supported hardware or emulation.
The intended delivery consists of three packages:
| Package | What an engineer should receive |
|---|---|
| Reference environment | Installation instructions, a versioned workload image, example inputs, a supported configuration and a threat model identifying the trusted host, runtime and connectors. |
| Developer SDK and CLI | Interfaces for task permissions, tool invocation and structured denial or failure results; examples for configuring resource limits and inspecting effective access. API and language support will be established during prototyping. |
| Evaluation kit | A repeatable runner, legitimate and adversarial test cases, outcome checks performed outside the tested workload, and an exportable report recording configuration, observed behavior and resource cost. |
Evaluation will distinguish deterministic boundary tests from repeated agent trials, whose outcomes may vary. Reports should record policy, software and hardware versions, test coverage and known gaps. Hardware emulation can support functional experiments; performance and energy claims require suitable measurement on the relevant platform.
From reference platform to supported offering#
The initial commercial hypothesis is a paid evaluation and integration for one partner workflow. The proposed engagement would deliver a working integration, an agreed permission model, protection tests, resource measurements and a recommendation on adoption. Acceptance criteria would be agreed before the evaluation.
As demand becomes clearer, the platform could grow into supported deployment profiles, application frameworks and an operator interface for reviewing policies, execution records and evaluation results. Hosted services, additional device targets and custom hardware would follow demonstrated requirements and suitable resources. The roadmap sets out the delivery stages and evidence needed to advance.
Execution boundaries address defined access and fault properties. Model quality, the handling of permitted data and domain-specific assurance remain part of the surrounding application design.
Engineering foundations#
Our design draws on established work in runtime policy and isolation, hardware–software memory protection and isolated evaluation environments. These are technical references, with distinct scopes and assumptions. Our research agenda explains the broader design space; the product above is AGIACC’s proposed direction.
Discuss a platform evaluation · Explore the delivery roadmap