Introduction

DevOps teams ensure the availability, evolution, and security of increasingly complex application environments on a daily basis. Investigating an alert, updating a dependency, or changing infrastructure often involve the same activities: gathering context, analyzing symptoms, modifying code, running verifications, and preparing a decision.

Today, I firmly believe that the future of this field lies in the engineering of agentic platforms that can take on part of this work through software agents capable of using tools and pursuing a mission over time. I am also convinced that the goal is not to replace the engineer, but to provide operational support while preserving the team’s review and delivery processes.

For example, following a request or a monitoring alert, an agent could inspect monitoring metrics, investigate an issue, and prepare a change in GitLab. It would report its findings, ask for clarification if needed, and submit its changes for review. Required approvals and delivery to application environments would remain governed by existing processes.

Overview of interactions between the DevOps engineer, autonomous agents, monitoring, GitLab, and application infrastructure

High-level principle: agents assist the team and use the tools available to them; humans retain the decisions and approvals that belong to them.

Today, the use of artificial intelligence in enterprise IT operations essentially comes down to two approaches:

  1. The workstation-dependent assistant: assistants embedded in IDEs provide helpful support to developers, but their presence on the workstation and the step-by-step validation of commands do not, on their own, constitute an industrialized execution platform.
  2. The autonomous agent without a trust framework: autonomous agents are beginning to be experimented with, but granting them production access without isolation or independent controls exposes the organization to errors, prompt injections, and privilege abuse.

Neither of these two solutions being satisfactory, the future lies in bounded autonomous agents with their own dedicated execution resources, rather than an unlimited delegation of authority to a model. These agents must integrate into engineering processes as members of the technical team, while being subject to strengthened requirements for traceability, isolation, and validation.

Even if the IDE can remain a control interface, background execution and its privileges must not depend on the resources or credentials of the developer’s workstation.

To make this vision a reality, my target platform relies on a Cloud provider (GCP), an agent orchestrator (Google AX), a sandbox (Agent Substrate), and tools (OpenCode, MCP, etc.). The harness designates the software environment that turns the generative AI model into an agent: execution loop, tools, context management, and interactions with the sandbox. The model is merely one component of this system.

This manifesto describes a set of requirements I hold myself to, and in no way represents a certification of the current implementation. The mechanisms mentioned must be qualified and validated before being used.

Part 1: Governance Rules and DevOps Process Integration

1. The human retains decision-making authority

My conviction: autonomy must operate within an explicit boundary. The agent can investigate, propose, and execute authorized operations; it can neither grant itself new privileges nor assign itself human approval.

The method:

  • The engineer shifts from the role of code or infrastructure craftsman to that of supervisor: formulating a mission, setting constraints, and arbitrating structural decisions.
  • The platform authenticates the requester, whether human or system, and verifies their authorization to launch a mission on the targeted project and scope. Automated triggers, notably monitoring webhooks, are authenticated, authorized, and protected against replay attacks; their origin is preserved in the mission trace.
  • Certain routine operations may be pre-authorized via a policy or a runbook. However, critical mutating actions require explicit approval proportional to risk.
  • When context remains ambiguous, the agent requests a human decision via a dedicated tool (for example, of type ask_human). The platform manages its suspension and resumption.
  • Segregation of Duties (SoD) is enforced by design outside the agent: author, approver, and deployment identity are distinct. The agent cannot approve its own contribution, modify approval rules, or bypass the pipeline.
  • An approval is bound to a specific target: repository, MR, commit SHA, environment, and operation. Any relevant modification to the content requires renewed validation.
  • If a required GitLab feature depends on an unavailable tier or edition, an equivalent independent control must be established and tested; a prompt is not an acceptable substitute.

References: R02, R13, R14, R16.

2. Reviewed code and a governed delivery pipeline are the path to production

My conviction: an agent must never directly alter a production cluster or cloud resource through an arbitrary command. Application and infrastructure changes must follow the exact same governed process as those made by engineers.

This rule does not conflate production changes with sandbox provisioning or business state updates performed by the control plane within a pre-authorized scope.

The method:

  • Agents work on dedicated branches, open Issues, and submit Merge Requests. They monitor pipelines and remediate failures without weakening controls.
  • The delivery pipeline validates, builds, and promotes artifacts from staging to production according to required permissions and approvals.
  • Security and release gates cannot be unilaterally altered by the agent whose work they evaluate.
  • The origin and integrity of commits and artifacts are attested through signatures and provenance attestations tied to the tested commit SHA and deployed digest. If an agent-dedicated GPG signature is used, its private key remains in a trusted signing service outside the sandbox.
  • A signature attests to origin and integrity; it proves neither code quality nor human approval.
  • History relies on protected Git references, CI attestations, and a tamper-resistant audit log. Git alone does not make all repository administration inviolable.
  • Rollback is prepared and tested: a git revert alters versioned intent, but does not instantaneously revert a data migration or infrastructure deletion.

Whether delivery is executed via a CI/CD pipeline (terraform apply) or a continuous reconciliation controller (GitOps), Git remains the sole entry point into production.

References: R05, R16, R17.

3. Human oversight must withstand approval fatigue

My conviction: multiplying vague approval requests leads to rubber-stamping. The quality of the decision dossier matters more than the number of clicks.

The method:

  • Approval requests are consolidated into Merge Requests. When an agent requires additional privileges (for example, authorization to access a new egress URL), this request is submitted as a Merge Request and versioned in a dedicated GitOps repository, guaranteeing full auditability.
  • Each Merge Request or approval request provides a concise dossier: problem statement, root cause hypothesis, proposed changes, test evidence, impact analysis, uncertainties, and rollback plan.
  • A model-generated hypothesis is strictly distinguished from a tool-verified fact.
  • Expired or stale requests are flagged. A response must not trigger a different task or validate a new commit SHA without the reviewer’s explicit knowledge.
  • The platform measures supervision overhead: requests per task, response lead times, and post-approval failure rates.

References: R03, R14.

4. Context is versioned code, not an authorization

My conviction: local knowledge must live as close to the code as possible. It must not be conflated with platform security policies.

The method:

  • Files such as AGENTS.md, opencode.json, build instructions, and repository conventions evolve through review, exactly like other engineering files.
  • Cross-cutting rules, skills, and policies are centralized and versioned. The platform records the exact versions utilized for each execution.
  • Trusted instructions are separated from external data: Issues, CI logs, documents, web pages, tool descriptions, and MCP results are treated as untrusted content.
  • Inputs are selected, bounded, and parsed before entering context. Truncated content is explicitly marked as incomplete and remains retrievable through a controlled pathway.
  • Filters, including Model Armor once its integration is qualified, complement this separation. They reduce prompt injection risk; they do not guarantee its complete elimination.
  • Permissions, budgets, and approval rules are enforced by trusted components, even if the model ignores instructions or the repository contains adversarial guidance.
  • The learning context is a first-class engineering asset. An agent is only as good as the context it is given: skills (how to do things) and memory (what the team already knows) are crafted, tested, and improved like code. An agent without memory starts from scratch on every mission and repeats the same mistakes.
  • Shared memory takes the form of a Markdown wiki versioned in Git (architecture decisions, post-mortems, conventions, known pitfalls), readable by engineers and agents alike. What the team learns benefits everyone.
  • The agent may propose writes to this memory (a lesson learned, a fix to an outdated page), but only through a merge request reviewed by a human. Unreviewed knowledge never becomes an instruction: this prevents an error or poisoned content from propagating from mission to mission.
  • Each memory page has an owner and a last-reviewed date; stale knowledge is fixed or removed. The wiki remains context, never an authorization.

References: R04, R13, R21.

Part 2: System Architecture, Scalability, and Tooling

5. Dialogue, orchestration, and execution are decoupled

My conviction: the conversational interface must not be blocked by a compilation, a prolonged investigation, or a wait for human input. This decoupling does not necessitate multiplying agents or models without need.

The method:

  • A Copilot-style chat interface handles dialogue, intent comprehension, and high-level steering; execution agents are provided with a dedicated sandbox, filesystem, and required developer tooling.
  • The durable log, authority controls, and recovery mechanisms do not rely on the survival of the single process running the code.
  • Execution capacity is allocated on demand according to admission limits and the genuine requirements of the task.
  • Multi-model routing is governed: a fast, cost-effective model handles simple requests; a more capable model is engaged only when benchmarks demonstrate its value.
  • The router weighs quality, cost, latency, confidentiality, tool capabilities, and geographic constraints. Model escalation must never expand the agent’s permissions.
  • When a parser, compiler, or deterministic rule suffices, a model should not be invoked simply to inspect a structure or reformat JSON.

References: R01, R02, R10.

6. Orchestration is asynchronous, durable, and concurrency-aware

My conviction: an engineering mission outlives the lifecycle of a single network request. Its state and decisions must survive restarts, delayed responses, and duplicate event deliveries.

The method:

  • A message middleware, such as Pub/Sub, separates commands and events into two logical topics (commands and events). These are not two distinct middlewares.
  • A state store such as Firestore serves as the operational source of truth for conversations, missions, executions, questions, permissions, and correlations. GitLab remains the authority over its Issues, MRs, and pipelines; the agent orchestrator remains the authority over its execution resources.
  • Each event and execution attempt carries a unique identifier. Task state transitions (working, input-required, completed, failed) are deduplicated and protected against delayed or out-of-order deliveries.
  • External calls (GitLab API, event publishing) require explicit recovery mechanisms, as a database transaction cannot span an external network call. Repeated operations, such as creating an Issue, rely on correlation IDs and deduplication or reconciliation logic suited to the target service.
  • The UI receives persisted, resynchronizable projections, for instance via SSE. A browser disconnection must not drop a pending question or turn a waiting state into an apparent success.
  • Concurrency is controlled per target: multiple agents can analyze or work concurrently across isolated branches and perform authorized GitLab operations. Human replies and resumptions are tied to the appropriate mission and its current state; conflicting mutations on the same object are coordinated to prevent collisions.
  • Production transitions through Git and CI/CD: agents do not directly mutate production resources or manipulate delivery infrastructure locks. The CI/CD pipeline executes these actions and leverages Terraform state locking when supported by the backend.

To facilitate dialogue between the supervisory chat agent and background execution agents, this orchestration draws upon the A2A (Agent-to-Agent) protocol and its task lifecycle (working, input-required, completed, failed). While an internal Pub/Sub bus suffices for internal transports, opening the platform to third-party A2A-compliant agents requires implementing its explicit protocol contracts (HTTP, SSE, and asynchronous notifications).

References: R01, R06, R19, R20, R26.

7. MCP standardizes integrations; independent controls bound authority

My conviction: integrations must be modular and explicit. A shared protocol streamlines evolution without constituting a security boundary on its own.

The method:

  • Sandbox integrations favor specialized MCP servers running over local stdio transports, notably for GitLab interactions and human exchanges.
  • Tools are described by schemas, discovered, and invoked in accordance with the adopted MCP version. A compatible interface enables harness evolution without rewriting integration logic.
  • Files, compilers, test runners, and Git commands can remain local harness tools. Shell or CLI access must never bypass authorizations enforced on external accesses.
  • Tool supply chain is qualified: approved sources, pinned versions, verified digests or hashes, inventoried dependencies, and evaluated updates.
  • Signatures (e.g., using Cosign) and provenance attestations rely on an explicitly defined trust chain. Trusted signing identities and private keys remain outside the untrusted runtime.
  • Binary Authorization can enforce admission policies on GKE images. It does not automatically validate MCP servers downloaded post-startup; such extensions require their own controls.
  • A valid signature does not guarantee that a tool is free of defects or malicious behaviors. Tool descriptions and outputs remain subject to untrusted data isolation.

References: R07, R15, R17, R18, R27.

8. Favor deterministic tools rather than letting the model guess (Deterministic-First)

My conviction: a Large Language Model (LLM) is probabilistic: it excels at analyzing problems and generating code or configurations, but it must never be asked to guess or simulate what a deterministic tool (compiler, linter, test suite) can verify with exactitude.

The method:

  • The agent uses the model to analyze needs and formulate changes, then strictly executes deterministic tools within its sandbox (linters, compilers, terraform validate, helm template, unit tests, and security scanners) before pushing code or requesting human review.
  • Proof of operational correctness rests on actual tool outputs (commands executed, return codes, and test artifacts) linked to the evaluated code, never on an unverified model assertion that code is valid.
  • Any required check that is skipped or failed remains visible and halts the progression: the agent must remediate its code or escalate the blocker without bypassing the check.
  • A passing test validates the scenarios it covers under its execution conditions, while maintaining reproducible, measurable compute costs.

References: R02, R12.

Part 3: Security, Identity, and Data Protection

9. The runtime is untrusted; secrets and authorizations remain under external control

My conviction: an agent reading external sources and executing code must be considered potentially compromised. Zero-secret isolation reduces credential exposure; it does not remove the authority of permitted operations.

The method:

  • Isolation: each task runs in a sandbox isolated from other workloads. gVisor provides an application kernel in user space; it is not, by definition, a micro-VM hypervisor. Execution mode, mount boundaries, and containment parameters must be explicitly documented.
  • Dedicated identity (Non-Human Identity): each task carries a distinct logical machine identity; each execution bears an attested capability bound to requester, repository, target, and authorized policy. A deterministic proxy/firewall appliance derives this identity from a platform-controlled context to authorize or reject traffic.
  • Least privilege: permissions granted to an agent are time-bound and restricted strictly to projects, branches, and operations necessary for its mission.
  • Externalized credentials: GitLab PATs, integration OAuth tokens, and trusted signing keys are never handed over to the sandbox or the agent. The agent uses placeholders or bounded local capabilities; genuine credentials are held by a trusted component (proxy/firewall).
  • Lifespan and revocation: the platform prioritizes short-lived tokens where provider capabilities exist (such as Cloud OAuth tokens). When target services rely on longer-lived credentials (such as GitLab PATs), an egress proxy bounds authorization to task duration and enables immediate revocation.
  • Governed egress: the external proxy validates destinations and operations, then injects the appropriate credential. Simple domain allowlists are insufficient: an allowed domain may host distinct targets or receive unintended data exfiltrations.
  • Inputs and outputs: external data and tool responses are parsed, minimized, and bounded. Model Armor and analytical rules complement authority boundaries; they replace neither isolation nor authorization.
  • Confidentiality: application secrets, personal data, and confidential materials are subject to classification and redaction policies prior to model submission or storage. Withholding credentials from the agent does not guarantee that scanned files contain no secrets.
  • Data residency and sovereignty: beyond governing the execution platform (cluster, sandboxes, micro-VMs), explicit governance must be defined for data locality and inference services. Storage locations (databases, snapshots, logs) and LLM inference endpoints are evaluated separately: hosting infrastructure in Europe is insufficient if the model is invoked via a global endpoint. The platform enforces regional endpoints matching selected residency requirements without automated fallback to unauthorized regions or vendors. A regional endpoint does not, however, suffice on its own to establish sovereignty: provider commitments, metadata handling, support access protocols, and subcontractor engagements must be reviewed against applicable standards.

References: R01, R03, R08, R09, R13, R21, R22, R23.

Part 4: Operations, Reliability, and FinOps

10. Execution is disposable; useful state and resume capabilities are durable

My conviction: mission survival must not depend on legacy server quirks (manual configurations, remnants of prior runs, etc.). Likewise, waiting for human feedback never justifies leaving an active compute process running indefinitely.

The method:

  • Every new execution receives a controlled environment, provisioned cleanly or explicitly restored. Remnants from other agents are never implicitly reused.
  • Upon execution conclusion, useful files, Git references, queries, and workflow states are archived (in cost-effective storage) prior to releasing execution capacity.
  • Disk snapshots enable cold restarts; they do not guarantee in-memory state or process restoration. Resumption verifies execution identity, authorizations, and response validity.
  • Capacity reclamation operates under a measured SLO. A failed snapshot or unstopped process is surfaced, not masked behind a success status.
  • Task suspension releases active agent capacity; worker nodes, shared databases, network fabrics, and storage layers may continue incurring costs.
  • TTLs and garbage collection tasks, triggered for instance via webhooks (using Cloud Scheduler cron triggers), adhere to resource ownership and evidence retention policies.
  • Business continuity spans backups, restorations, model outages, and environment recovery. RTO and RPO objectives are defined and tested.

Global Emergency Stop (Kill Switch): an authorized operator must be able to halt the intake of new missions, quarantine offending triggers, block sensitive operations at the proxy level, and terminate active executions. This control and its audit trail operate independently of LLM cooperation.

Queues, DLQs, logs, and snapshots are preserved by default for forensic analysis and recovery. Purges remain exceptional, authorized, and documented. In-flight operations are reconciled prior to controlled, idempotent resumption; an emergency stop cannot magically undo already-committed external side effects. Stop propagation latency is benchmarked, and manual operational fallback procedures are documented.

References: R01, R09, R10, R14, R15, R26.

11. Strict budgetary and anti-loop guardrails (Cognitive FinOps)

My conviction: an autonomous agent facing a complex error can easily enter an infinite trial-and-error loop, consuming millions of tokens within minutes without convergence. Guardrails must be enforced and blocking, not limited to retrospective billing alerts.

The method:

  • Per-mission quotas (Circuit Breakers): each task is constrained by a maximum step count, maximum execution duration, and maximum token/LLM call budget, encompassing retries and sub-tasks.
  • Dual enforcement (internal and external): the agent harness monitors thresholds at every iteration, while an out-of-sandbox proxy physically blocks outgoing calls to model APIs once quota limits are reached.
  • Blocking ceilings over reactive alerts: cloud billing alerts notify post-facto without severing active calls; the platform enforces real-time counters per task and evaluation window. Parallel requests are accounted for during admission (e.g., through budget pre-reservations) and subsequently reconciled with actual consumption.
  • Termination and escalation: when a task exhausts its quota without converging, the platform blocks new invocations, issues an execution shutdown, and delivers an incident diagnostic to the engineer without initiating further LLM calls. In-flight requests may complete and incur additional costs; their usage is tracked and any budget overrun is flagged.
  • Total cost tracking and optimization: FinOps tracking accounts for complete expenditures (tokens consumed including failed iterations, sandbox compute time, and shared infrastructure costs) attributed to each validated outcome. Leveraging lighter models, prompt caching, and context pruning optimizes costs without sacrificing quality or data confidentiality.

References: R02, R10, R24.

12. Auditing covers observable decisions, actions, and evidence

My conviction: post-incident analysis requires an actionable execution trajectory. This does not imply possessing an exhaustive or faithful copy of the model’s internal cognitive process.

The method:

  • Audit traces correlate requester, task, execution, identity, model version, context version, tool versions, invocations, outputs, errors, approvals, commit SHAs, generated artifacts, and reported usage.
  • The durable log is secured against tampering by the agent and enables full reconstruction of observed events.
  • Explicit hypotheses and justifications from the model are separated from tool-generated proofs. Available reasoning summaries aid diagnostic investigations without being misconstrued as exhaustive proofs of internal computation.
  • The platform does not require capturing private chain-of-thought tokens as an audit prerequisite.
  • Data is minimized and filtered prior to ingestion into log stores and before dispatch to inference APIs. Sensitive Data Protection (formerly Cloud DLP) can support redaction pipelines.
  • Redaction, pseudonymization, and anonymization are not interchangeable. Detection mechanisms cannot guarantee discovery of all secrets; access controls, encryption, processing locations, and retention rules remain mandatory.
  • Granular execution traces are private by default. Access permissions and collection exceptions are governed and audited.
  • OpenTelemetry GenAI semantic conventions can assist signal interoperability; their version and scope must be specified.

References: R11, R12, R14, R22, R25.

13. Agents are evaluated as complete systems

My conviction: altering a model, system prompt, tool, or policy control can silently degrade overall reliability. Qualification must address the complete system, not merely standalone model outputs.

The method:

  • A test harness incorporates reference repositories, known bugs, failing CI pipelines, dependency upgrades, and monitoring incidents.
  • Multiple evaluations run per benchmark scenario to quantify stochastic variance. Success rates, regressions, costs, latencies, forbidden action attempts, and human intervention rates are systematically tracked.
  • Capability evaluations are distinguished from non-regression testing. Promotion thresholds are defined, and results are permanently linked to the specific evaluated versions.
  • Task completion is validated in the execution environment: correct code modifications, on the correct target, accompanied by expected proofs and approvals. A model asserting “task complete” is never proof of completion.
  • Adversarial test cases explicitly cover indirect prompt injections, data exfiltration, self-approval bypasses, unauthorized tools or container images, duplicate event deliveries, post-pause resumptions, quota overruns, and emergency kill-switch activations.
  • Storage failures, infrastructure outages, and recovery workflows form an integral part of qualification suites. Simulated tests are strictly separated from integration and live-deployment evidence.
  • Any update failing quality criteria is rejected for promotion. A passing benchmark measures covered behaviors; it never certifies absolute security.

References: R12, R13, R14, R15.

From Manifesto to a First Pilot

To bridge theory into practice, adoption must follow an incremental and pragmatic path:

  1. A restricted starting scope: start with a pilot team across a select few repositories, strictly addressing simple, low-risk use cases (such as analyzing a failing CI pipeline or preparing a dependency upgrade Merge Request). Standard rules remain in place: humans approve and CI/CD deploys.
  2. Simple success metrics:
  3. Effectiveness: is the task resolved without manual rework?
  4. Time savings: does the engineer genuinely save time without suffering from approval overload?
  5. Cost: what is the total true cost (tokens and cloud compute) per successful task?
  6. Security: strict compliance with guardrails (zero bypasses, zero forbidden actions).
  7. Controlled scaling: the platform’s scope expands to additional projects or more complex tasks only after these initial outcomes are validated alongside the team.

Conclusion

Industrializing AI for DevOps does not mean finding a magical model and handing it the keys to the kingdom. It means engineering the system that bounds and governs its autonomy.

The goal is a platform where agents can efficiently produce, test, and investigate, but can neither elevate their own privileges, nor approve their own work, nor conceal their failures. Authority, verifiable evidence, and operational durability must remain independent of an untrusted and potentially compromised runtime.

Isolation, externalized credentials, access policies, governed delivery pipelines, operational budgets, resilient recovery, and comprehensive evaluations turn this ambition into a verifiable reality. Production readiness is a qualification that must be demonstrated, not an assumed property emerging from an assemblage of technologies.

References and Scope of Sources

Primary sources consulted on November 8, 2026. Protocol specifications, risk frameworks, product documentation, and industry postmortems carry distinct scopes. They inform these principles without certifying this specific platform or mandating a single architecture. Applicable versions and vendor commitments must be validated during implementation.

Ref. Source Key Contribution and Limitation
R01 Anthropic — How we built Claude Managed Agents Separation of harness, sandbox, and durable session; externalization of credentials. Engineering retrospective, not an obligation to duplicate the service.
R02 Anthropic — Building effective agents Workflows, routing, agents, and exit criteria; favor simplicity and justify added complexity.
R03 Anthropic — Claude Code sandboxing Approval fatigue, isolation, and controlled authentication proxy; does not automatically validate our custom configuration.
R04 AGENTS.md — official project Open specification for repository context and local instructions; not an authorization policy.
R05 OpenGitOps — principles Declarative, versioned and immutable, automated pull, and continuous state reconciliation.
R06 A2A — official specification Data models, operations, and communication transports for interoperability; an internal message bus is not sufficient to establish compliance.
R07 MCP — architecture Context and tool interface contract, client/server architecture, and transports; does not dictate the agent’s internal architecture.
R08 NIST SP 800-207 — Zero Trust Architecture Resource-centric authorization without implicit network trust; not a vendor proxy certification.
R09 gVisor — architecture overview Application kernel, isolation boundaries, and security limits, particularly within the workload container.
R10 FinOps Foundation — FinOps for AI Overview Total cost of ownership, attribution, and cost per successful outcome; extends beyond raw token consumption.
R11 Anthropic — Reasoning models don’t always say what they think Empirical counter-examples regarding chain-of-thought fidelity; an execution trace is not exhaustive proof of reasoning.
R12 Anthropic — Demystifying evals for AI agents Harness and model evaluation, repeated trials, real-world outcomes, capabilities, and regression prevention.
R13 OWASP GenAI — Top 10 LLM and LLM01 Prompt Injection Indirect inputs, content segregation, least privilege, and adversarial testing; makes no claims of infallible prevention.
R14 NIST — AI Risk Management Framework Lifecycle governance and risk management; voluntary framework, not a production certification.
R15 Google — Secure AI Framework (SAIF) Security foundations, detection, response, and consistent controls; conceptual framework.
R16 GitLab — merge request approval settings Exclusion of author or contributors, rule locking, and approval invalidation; features depend on subscription tier.
R17 SLSA — framework Supply chain integrity and security assurance levels; target level and attestation evidence must be explicitly specified.
R18 Google Cloud — Binary Authorization Container image admission policies and cryptographic attestations; does not monitor in-sandbox downloads after container startup.
R19 HashiCorp — Terraform state locking State write locking when supported by backend; must not be replaced by a simple dispatcher-level lock.
R20 Google Cloud — Firestore transactions Atomic writes and transaction retry semantics; does not provide a global distributed transaction spanning external GitLab APIs.
R21 Google Cloud — Model Armor Input/output analysis and threat detection thresholds; operational trade-offs between false positives and false negatives.
R22 Google Cloud — Sensitive Data Protection Inspection and de-identification transformations; coverage is bounded by selected detectors and rule configurations.
R23 Google Cloud — data residency and ML processing Distinction between storage and processing, with commitments differentiated by model and endpoint; a global endpoint does not guarantee regional residency.
R24 Google Cloud — budgets Differentiates notification-only alerts from programmatic spend caps; service coverage must be verified.
R25 OpenTelemetry — GenAI conventions Semantic telemetry conventions for spans, metrics, and events, including MCP; version and coverage must be qualified.
R26 Google Cloud — Pub/Sub exactly-once delivery Conditional delivery guarantees; does not grant automatic idempotency to downstream workflow side effects.
R27 MCP — security best practices Risks and mitigations specific to MCP integrations; complements but does not replace foundational trust boundaries.