Prompt-to-Paper: Agentic AI System for Bioinformatics

Status: public draft. This blueprint is an evolving line of research for Secure AI Atlas. It applies the core governance principles of the general Agentic AI Governance Blueprint to a concrete, high-risk use case: the automated generation of a publishable bioinformatics manuscript from a raw research prompt. It is not a finished commercial product, a certification scheme, or a substitute for legal, security, or risk assessment.

An agent becomes a governance problem when language can cross into action: editing content, changing code, querying data, calling tools, moving records, or influencing a decision. In the Prompt-to-Paper case, language crosses a particularly consequential boundary: from an informal research idea to a structured scientific document that could enter the peer-reviewed literature.

Use case summary

The system accepts a free-form research prompt from a scientist (for example, “analyze RNA-seq data for circadian rhythm genes in mouse liver”). The agentic system then decomposes this goal into sub-tasks, retrieves or generates data, executes bioinformatics analyses, interprets results, and composes a complete manuscript — including a structured abstract, introduction, methods, results, discussion, figures, tables, references, and supplementary material — for human review and potential submission.

The control objective is not to eliminate the utility of automated manuscript drafting. It is to make every scientific decision traceable, every pipeline execution verifiable, every knowledge claim attributable to its source, and every approval — or rejection — transparent and irreversible.

Purpose

This Prompt-to-Paper governance blueprint provides a practical structure for designing, limiting, recording, and reviewing an agentic system whose outputs are not operational code or internal data but public-facing scientific publications.

It is intended to connect system design with governance evidence. An agent that drafts a manuscript should not be described only by its underlying language model or interface. It should be described by what data it can access, which analytical pipelines it can execute, how it selects references, which rules constrain its scientific claims, how it handles negative or ambiguous results, which human reviewers examine each section, and who accepts the remaining risk of publishing automated analysis.

Audience

The blueprint is for bioinformatics platform teams, scientific software engineers, research integrity officers, journal editors evaluating AI-assisted works, institutional review boards, AI and application security engineers, governance and risk functions, and the scientists who will review, amend, and take responsibility for the final manuscript.

It applies to any agentic system that generates structured scientific documents from unstructured prompts. The same control questions apply whether the agent is a local research assistant pipeline or a cloud-hosted manuscript service.

Problems it addresses

• A scientist can describe a complex bioinformatics analysis in natural language, but the agent’s decomposition of that prompt into pipeline steps, parameter choices, and interpretation logic is opaque to reviewers.
• Permissions for data access (raw sequencing files, clinical metadata, restricted databases) are inherited from the requesting user without being reduced to the minimum necessary for the manuscript’s stated scope.
• Each tool call — a read alignment, a differential expression test, a gene-set enrichment analysis — turns a probabilistic model decision into a deterministic scientific output that may be cited or challenged.
• Prompts, retrieved literature, reference genome files, and intermediate pipeline outputs cross trust boundaries without consistent validation. A single contaminated reference or adversarially crafted input could propagate into a published result.
• Human review exists as a final read-through rather than an enforced decision point at each layer: methods design, statistical validity, interpretation strength, and disclosure of AI involvement.
• Logs capture the conversation with the scientist but omit tool arguments, pipeline configuration, software version provenance, random seeds, parameter grids, and the reasoning path that led from data to conclusion.
• Reviewers cannot reconstruct why a particular statistical test was chosen, which reference guided an interpretation, whether a negative result was filtered out, or how to reproduce the analysis from the raw prompt.
• A successful manuscript draft becomes an implicit grant for the agent to propose broader claims, use more sensitive data, or skip validation steps in subsequent drafts.

Principles

0. Inventory first, control second. No control — permissions, logging, approval, review — can be applied until the agent, its analytical pipelines, data classes, reference sources, figure-generation tools, identities, and reachable publication systems are inventoried. A manuscript-generation system that cannot enumerate its own analytical dependencies is not governable.

1. Authority must be designed, not inferred. Define what the agent may analyze, which statistical methods it may select, which databases it may query, and which interpretive claims it may make — before the first pipeline is connected.

2. Identity belongs to the workload. Use attributable agent and service identities for each analytical step. A differential expression analysis and a figure-generation step should not share the same identity, credential, or audit trail.

3. Least privilege is task-specific. Restrict data scope to the stated analysis, limit database queries to the required fields, constrain statistical methods to a validated allowlist, and set per-pipeline resource and rate limits — not only broad database roles.

4. Treat every input as a trust-boundary crossing. The research prompt, retrieved literature, reference genome files, annotation databases, intermediate pipeline output, and messages from chained sub-agents may contain instructions, biases, or poisoned context that could alter the manuscript’s scientific claims.

5. Separate recommendation, approval, and execution. Pipeline design, parameter selection, result interpretation, figure generation, abstract writing, and submission recommendation should not collapse into one model turn or one identity. Each layer deserves independent scrutiny.

6. Make consequential action observable. Record the decomposition decisions, pipeline invocation, parameter values, software versions, reference selections, confidence scores, failure modes, human interventions, and the chain of reasoning for every scientific claim. Observability requires an Evidence Channel — a separate flow that exposes sources, references, and reasoning alongside the interaction channel. A reviewer who sees only the final manuscript PDF cannot distinguish a grounded statistical analysis from a plausible-sounding pipeline hallucination.

7. Prefer reversible operations. Use previews, branch- or version-controlled manuscript drafts, staging analysis environments, intermediate checkpointing, and time-bounded data-access grants. A manuscript that can be rolled back to the previous version is safer than one that was overwritten.

8. Human review must have leverage. A scientist reviewing the methods section needs enough evidence, time, domain competence, and technical ability to challenge the statistical approach, request an alternative analysis, or reject the manuscript entirely at any stage.

9. Autonomy expands only through evidence. Permission to access a restricted clinical database, to use a more complex statistical model, or to propose stronger conclusions requires a new risk decision informed by the track record of previous verified analyses — not accumulated familiarity with the tool.

10. Failure must reduce authority. A pipeline error, a data-access anomaly, an unexpected result that cannot be explained, or missing provenance evidence should move the system toward a safe state: reduced data scope, required human validation before the next step, or suspension of the manuscript generation pipeline.

Minimum controls

Inventory and ownership

Maintain an agent register for the Prompt-to-Paper system containing: purpose (the scope of bioinformatics manuscript types it may draft), owner, language model and runtime version, analytical pipeline inventory (each tool, method, database, or script), environment (staging, production for draft generation), data classes the agent may access (raw sequencing data, processed count matrices, clinical annotations, etc.), identities for each pipeline step, allowed actions (retrieve, align, quantify, test, annotate, plot, write, format), prohibited actions (access patient identifiers, modify raw data files, submit to journals, generate data without source provenance), approval thresholds (by section type, data sensitivity, and claim strength), dependencies (reference databases, annotation servers, compute clusters), review date, and retirement state.

Identity and permissions

Assign attributable workload identities for each analytical sub-agent. Enforce least privilege: the alignment sub-agent has read access to raw fastq files and write access to its own output directory only. The differential expression sub-agent has read access to the count matrix and clinical design file but not to raw reads. The figure sub-agent has read access to the results directory and write access to the figures directory but no access to raw data or patient metadata. Separate duties: the same identity should not perform the analysis and compose the narrative description of that analysis. Short-lived credentials where possible. Environment boundaries between staging and manuscript production. Explicit denial of unneeded methods (for example, the literature-retrieval sub-agent denies all data-analysis tools). Permission changes should be versioned and reviewed independently from prompt instructions.

Tools and execution

Allowlist analytical tools, statistical methods, and databases. Validate pipeline parameters against schemas and policy — for example, prohibit maximum-likelihood methods on count data with fewer than three replicates when the analysis plan did not specify that method. Constrain database destinations and query volumes. Isolate code execution for each pipeline step. Apply rate and cost limits per analysis job. Require dry-run or preview modes: a scientist should be able to review the proposed analytical pipeline, methods section, or figure layout before committing compute or generating the final draft.

Data boundaries

Classify data before the agent accesses it: public reference data, controlled-access clinical data, personally identifiable information, or restricted database schema. Limit retrieval scope to what the analysis plan requires. Protect secrets (database credentials, API tokens). Define retention: delete intermediate files after the manuscript is finalized or after a defined period. Prevent uncontrolled reuse of patient data in model memory or training sets. Validate outputs for sensitive disclosure: a manuscript must not inadvertently publish patient-level data or restrict-access genomic coordinates. Record which data sources influenced each section, claim, and figure.

Logging and evidence

Capture stable identifiers for the analysis job, the requesting scientist, the manuscript version, each sub-agent and its model version, pipeline definitions and version hashes, parameter values and random seeds, the exact references retrieved and selected, tool names and their inputs and outputs, authorization results for data-access decisions, human approval events, intermediate results at each stage, final manuscript sections and their provenance, errors and rollback actions, and all human edits made after draft generation. Logs must support scientific reproducibility without becoming an uncontrolled store of full raw sequencing files or restricted clinical data.

Human review and approval

Define approval by impact class: access to new controlled-access datasets, addition of a new statistical method to the allowlist, expansion of the manuscript to include human-subject data, production deployment after a pipeline change, external sharing of draft results, conclusions that make strong causal or clinical claims, decisions to omit a sensitivity analysis or negative result, and exceptions to the analytical policy must each require an authorized human before execution. The approval event must be technically enforced and linked to the exact proposed pipeline or section.

Assurance and response

Test prompt-injection paths (can a genome sequence interpreted as an instruction alter the analytical pipeline?), poisoned reference data (can a crafted annotation database change interpretation results?), authorization bypass (can the variant-calling sub-agent access the patient demographics table?), unsafe tool composition (can the literature-retrieval sub-agent invoke the figure-generation tool?), excessive agency (can the agent submit to a preprint server?), logging gaps (can a pipeline step complete without recording its parameter set?), denial of service (can a prompted analysis exhaust compute budget?), and rollback (can the system revert to a previous manuscript version?). Monitor production behavior: track pipeline failure rates, rejection rates at human review steps, time from prompt to complete draft, and types of scientific errors caught by reviewers. Define kill and containment paths: a single compromised pipeline step should not halt the entire manuscript generation. Investigate anomalies and tighten permissions after each review finding.

Operational cycle

1. Register — name the manuscript use case, the requesting scientist, the data scope, the intended analysis pipeline, the reference databases required, and the expected manuscript type (research article, review, method note, etc.).

2. Map — identify each analytical capability, the identity used for each pipeline step, the data categories and databases reachable, the tools and statistical methods, the output destinations (local files, preprint servers, journal submission systems), decisions (which method to apply, which result to highlight, which reference to cite), dependencies (reference genome version, annotation version, software libraries), and threat paths (prompt that requests a restricted method, prompt that attempts to access patient data, prompt that asks to fabricate results).

3. Bound — define allowed and denied analytical methods, least-privilege data access per pipeline step, budgets for compute and database queries, rate limits per analysis job, time limits for data retention, and human approval gates for each section type, claim strength, and data sensitivity level.

4. Test — exercise misuse inputs (prompts that request unvalidated methods, prompts that ask for conclusions not supported by the data, prompts that request access to restricted databases), adversarial inputs (a crafted fastq header that contains pipeline instructions), tool failures (reference database unavailable, pipeline software version mismatch), permission bypass (attempt to invoke a statistical method outside the allowlist), logging completeness (each pipeline step must produce a provenance record), rollback (revert a manuscript draft to a previous checkpoint), and safe-state behavior (a pipeline step that times out or produces anomalous results does not proceed to the next stage without human review).

5. Authorize — record the approving role (principal investigator, research integrity officer, data access committee), accepted residual risk (for example, the risk that a subtle reference bias may go undetected), evidence reviewed (the logged pipeline plan, method allowlist checks, data scope verification, and previous manuscript quality metrics), operating conditions (analysis may proceed only on this specific question, using these exact databases, for a maximum of three draft iterations), and expiration or review date for this authorization.

6. Operate — execute within the approved analytical envelope while policy enforcement and telemetry remain active. Each pipeline step logs its input, parameter set, version, output, and error state before the next step begins.

7. Review — compare the actual manuscript draft with the registered purpose. Inspect sections flagged by automated checks (methods section describes a method that the pipeline did not invoke, conclusion strength exceeds what the analysis supports, references are not from the allowed source list). Validate that each scientific claim is traceable to a pipeline output and parameter set. Inspect exceptions: sections that were rewritten by the scientist, methods that were substituted, results that were reinterpreted. Collect near misses: analyses that produced anomalous results caught by human review.

8. Change or retire — version material changes to the pipeline, the method allowlist, or the databases. Reassess expanded authority: permission to use a new statistical method or a more sensitive data set requires a new risk decision. Revoke access for the specific analysis job after the manuscript is finalized or rejected. Preserve the complete provenance record for the manuscript’s retention period. Close the use case with a summary of analyses performed, outputs produced, errors encountered, and lessons for the governance of the next manuscript.

Relationship between the control domains

Identity answers which agent or pipeline step is performing an analysis. Permissions define which methods, databases, and data fields that identity may access. Tools determine where model output can become a formal scientific claim. Data defines what the agent can observe, transform, retain, or include in a manuscript. Logging provides evidence of what was computed, selected, cited, rejected, and reviewed. Human review evaluates whether the analytical evidence, the scientific reasoning, and the resulting manuscript are acceptable for submission. Approval is the enforced decision that permits a high-impact manuscript section — a strong claim, a sensitive data citation, a clinical interpretation — to proceed to the next stage.

Weakness in one domain changes the meaning of the others. A method allowlist is not sufficient if the analysis sub-agent inherits read access to raw patient data that the analysis plan did not require. A human review screen is not meaningful if it hides the exact parameter choices and random seed used in a differential expression analysis. Complete logs do not compensate for an analysis that should never have been permitted because the data sensitivity exceeded the authorized scope.

Relationship to established frameworks

This Prompt-to-Paper blueprint is a domain-specific translation layer, not a replacement for established standards, journal policies, or applicable law.

• OWASP Top 10 for LLM Applications supplies an application-security threat lens. The blueprint turns concerns such as prompt injection, sensitive information disclosure, insecure output handling, supply-chain exposure (reference databases, annotation files, pipeline libraries), and excessive agency into boundaries for data, analytical methods, tools, permissions, and approval gates specific to bioinformatics manuscript generation.
• NIST AI Risk Management Framework supplies the broader risk-management structure. Its Govern, Map, Measure, and Manage functions inform ownership, context mapping for analysis pipelines, evaluation of scientific claim accuracy, monitoring of pipeline reliability and bias, and treatment across the manuscript generation lifecycle.
• MITRE ATLAS supplies an adversarial tactics-and-techniques lens for AI-enabled systems — including attacks on scientific pipelines, tampering with reference databases, and injection of misleading evidence. It supports threat modeling, test scenarios, detection hypotheses, and incident analysis around the Prompt-to-Paper workflow and its dependencies.
• EU AI Act supplies a legal and accountability lens where applicable. Inventory, role definition, risk classification, transparency regarding AI-generated content, logging, human oversight, technical documentation, and post-market obligations for a system that can generate scientific publications must be assessed against the actual system, its deployment context, and its legal role. This blueprint does not determine compliance or risk classification.
• NIST Zero Trust Architecture supplies the access model: no implicit trust based on location, explicit evaluation of access at each pipeline step, least privilege for each sub-agent, and policy enforcement close to each data source. Agent identity and analytical tool access should follow the same discipline.
• NIST Secure Software Development Framework supplies a Secure SDLC lens. Agent prompts, analytical pipelines, statistical method libraries, pipeline connectors, reference database versions, software dependencies and their provenance, code changes, test coverage, release management, and incident response should be handled as scientific software supply-chain concerns rather than informal scripting.

Possible future deliverables

This public draft may evolve into:

• a Prompt-to-Paper agentic governance assessment template;
• a minimum-control checklist by manuscript impact tier (preprint, conference paper, journal article, clinical report);
• an agent and analysis-pipeline register template specific to bioinformatics workflows;
• a control matrix mapping analytical risks, controls, pipeline owners, evidence types, and reference frameworks;
• a statistical method and database allowlist template;
• a human-approval threshold matrix by claim strength and data sensitivity;
• an operational approval and pipeline-exception runbook;
• test scenarios for prompt injection, poisoned reference data, unsafe pipeline composition, and rollback in a manuscript-generation context;
• a provenance evidence pack template for pre-submission peer review;
• a reproducibility checklist for automated bioinformatics manuscripts.

Current boundary

The first version defines questions and minimum evidence for one applied case: a bioinformatics manuscript generated from a research prompt. It does not yet define maturity scores, certification, legal conclusions, universal risk tiers, or a complete crosswalk to every referenced framework. It does not address image integrity verification, clinical trial reporting standards, or the full spectrum of AI-assisted scientific writing use cases (systematic reviews, grant proposals, regulatory submissions).

The blueprint will become useful only if it survives contact with real Prompt-to-Paper agent workflows. Future revisions should be driven by applied assessments, failed controls (including undetected scientific errors in generated manuscripts), review friction, journal feedback on AI-generated content, and evidence from rejected or corrected manuscripts that changes a governance decision.