119 lines
8.1 KiB
Markdown
119 lines
8.1 KiB
Markdown
# Research Brief
|
|
|
|
## Project identity
|
|
|
|
**Title:** Advanced Artifactual Intelligence Security Agent
|
|
**Status:** Public Contributing
|
|
**Short name:** AAISA
|
|
**Steward:** dTech Technology and Research Initiative
|
|
|
|
## Public description
|
|
|
|
An open, defensive research project building an evidence-first AI security agent that inspects software, model, prompt, dataset, configuration, and supply-chain artifacts for secrets, unsafe instructions, weak provenance, dependency risk, and policy violations. The agent operates locally by default, produces auditable JSON and SARIF findings, and is designed for human review and community-authored rules.
|
|
|
|
## Research problem
|
|
|
|
AI systems are assembled from more than executable code. Their security posture also depends on prompts, model cards, serialized weights, dataset manifests, dependency locks, deployment configuration, agent tool definitions, evaluation records, and provenance statements. These artifacts often cross trust boundaries, change at different rates, and are reviewed by different teams. Conventional application scanners cover portions of this surface but rarely preserve a single evidence model across AI-specific and software supply-chain artifacts.
|
|
|
|
AAISA investigates whether a constrained, explainable security agent can normalize these artifacts, apply transparent policies, and produce useful evidence without executing untrusted content or sending it to an external service.
|
|
|
|
## Central hypothesis
|
|
|
|
A local-first, rule-driven agent with explicit provenance, redaction, and human review boundaries can improve early detection of AI-system security risks while remaining auditable enough for research reproduction and contributor scrutiny.
|
|
|
|
## Objectives
|
|
|
|
1. Define a stable artifact and finding model that works across code, prompts, manifests, model metadata, datasets, and operational configuration.
|
|
2. Build a safe ingestion layer that hashes artifacts, enforces size limits, avoids symbolic-link traversal, and never executes inspected content.
|
|
3. Establish an extensible policy interface for deterministic rules and future isolated analyzers.
|
|
4. Produce portable JSON and SARIF evidence suitable for review, comparison, and integration.
|
|
5. Measure precision, recall, runtime, reproducibility, and analyst usefulness on transparent benchmark corpora.
|
|
6. Develop contribution, governance, disclosure, and rule-quality standards appropriate for an open security project.
|
|
|
|
## Initial research scope
|
|
|
|
The foundation covers local text artifacts and metadata. Initial rules examine likely embedded secrets, prompt-injection language, mutable dependencies, container tag ambiguity, and missing provenance fields. The first release deliberately avoids model execution, malware detonation, active exploitation, automatic remediation, network reconnaissance, and opaque risk scoring.
|
|
|
|
## Research questions
|
|
|
|
- Which artifact types and normalized attributes are required to express AI-specific security evidence without losing source context?
|
|
- Which deterministic rules provide useful early warning with acceptable false-positive rates?
|
|
- How should prompt-injection evidence be distinguished from benign documentation, test fixtures, and quoted attack examples?
|
|
- What provenance fields are minimally sufficient for models and datasets?
|
|
- How can community-authored rules be tested for safety, performance, redaction, and reproducibility?
|
|
- When should future probabilistic analyzers be allowed, and how should their confidence and model provenance be represented?
|
|
|
|
## Foundation architecture
|
|
|
|
The initial system has five layers:
|
|
|
|
1. **Discovery** enumerates regular files beneath approved paths while enforcing exclusions, size limits, and link boundaries.
|
|
2. **Normalization** records artifact type, path, size, SHA-256 digest, media type, and safely decoded text when supported.
|
|
3. **Policy evaluation** runs independent rules against immutable artifact evidence.
|
|
4. **Reporting** serializes redacted findings and scan metadata to JSON or SARIF 2.1.0.
|
|
5. **Human decision** remains outside the agent. The foundation reports evidence but does not modify artifacts or declare a system safe.
|
|
|
|
## Methodology
|
|
|
|
Research proceeds through versioned rules and public benchmark fixtures. Each rule proposal must include a threat statement, detection logic, expected evidence, remediation guidance, negative tests, positive tests, and known false-positive cases. Evaluations will use seeded and naturally occurring benign samples with secrets replaced by nonfunctional fixtures. Results will be recorded by rule version and corpus digest so another contributor can reproduce them.
|
|
|
|
## Evaluation plan
|
|
|
|
The project will track:
|
|
|
|
- precision and recall per rule and artifact class;
|
|
- false positives per thousand artifacts;
|
|
- scan throughput and peak memory by corpus size;
|
|
- deterministic report equality across repeated runs;
|
|
- percentage of findings with complete location, evidence, and remediation fields;
|
|
- redaction failures, which are release-blocking defects;
|
|
- analyst ratings for clarity, actionability, and time saved.
|
|
|
|
No aggregate score will conceal per-rule performance. Benchmark limitations and excluded artifact classes will be published with results.
|
|
|
|
## Safety and ethics
|
|
|
|
AAISA is a defensive research tool. The default implementation does not execute artifacts, make network requests, exploit targets, recover secret values, or apply automatic remediation. Reports redact matched credentials and should still be handled as sensitive security material. Test corpora must not contain live credentials, personal data without authorization, or malicious payloads that require execution.
|
|
|
|
Future active or probabilistic capabilities require a separate design review, explicit opt-in configuration, isolation controls, and documented evaluation. A finding is evidence of a condition to investigate, not proof of compromise. A clean report is not proof that a system is secure.
|
|
|
|
## Contributor workstreams
|
|
|
|
- Artifact schemas and parsers
|
|
- Rule engine and rule-quality tooling
|
|
- AI prompt and agent-configuration security
|
|
- Model and dataset provenance
|
|
- Software supply-chain and deployment policy
|
|
- SARIF and interoperability
|
|
- Benchmark corpora and evaluation science
|
|
- Privacy, redaction, and secure report handling
|
|
- Documentation, accessibility, and contributor experience
|
|
|
|
## Milestones
|
|
|
|
**Milestone 1 Foundation:** stable CLI, artifact model, built-in rules, JSON and SARIF reporting, tests, threat model, and contribution standards.
|
|
|
|
**Milestone 2 Evaluation harness:** versioned benchmark format, corpus digests, per-rule metrics, performance measurements, and regression thresholds.
|
|
|
|
**Milestone 3 Artifact expansion:** structured parsers for model cards, dataset manifests, agent tool definitions, SBOM formats, and selected deployment descriptors.
|
|
|
|
**Milestone 4 Controlled intelligence:** research optional probabilistic analyzers behind explicit isolation, provenance, confidence, and reproducibility requirements.
|
|
|
|
**Milestone 5 Pilot validation:** conduct approved, non-production pilots; publish limitations, measured results, and a production-readiness gap assessment.
|
|
|
|
## Foundation acceptance criteria
|
|
|
|
The foundation is complete when a clean checkout can run its tests with Python 3.11 or newer, scan the included examples without network access, emit schema-valid JSON and SARIF, redact secret matches, avoid symbolic-link traversal, return documented exit codes, and provide enough governance and technical documentation for a new contributor to propose a tested rule.
|
|
|
|
## Expected outputs
|
|
|
|
- A public Git repository with source, tests, examples, and contributor templates
|
|
- A reproducible command-line reference implementation
|
|
- A documented evidence schema and extension contract
|
|
- An open threat model and research roadmap
|
|
- Versioned research results and benchmark methodology in later milestones
|
|
|
|
## Licensing and governance
|
|
|
|
Source code is licensed under Apache License 2.0. Contributions are reviewed through pull requests. Security-sensitive reports follow the private disclosure process in `SECURITY.md`. Maintainers may reject rules that execute inspected content, expose secrets, introduce undisclosed network behavior, or cannot be tested reproducibly.
|