Pipeline Authoring Security
Pipeline Authoring combines repository editing, AI-assisted planning, generated code, validation, and publication. Qarion treats each of those as a separate authority boundary. A model suggestion is never itself permission to edit a repository, run a command, contact an external system, or publish code.
This guide explains the controls users and administrators encounter. For the end-to-end workflow, see Pipeline Authoring. For the final release gate, see Publish a Governed Pipeline.
Governed Authoring Flow
Qarion checks authority again at the boundary that performs an effect. A permission that existed when a task was planned is not assumed to remain valid when a queued worker resumes, a tool executes, a managed resource changes, or a publication starts. Revoked users, stale plans, changed repository heads, expired grants, and mismatched validation evidence fail closed.
Access Layers
Pipeline Authoring composes several access systems. Passing one layer does not bypass the others.
| Layer | What it controls | Typical requirement |
|---|---|---|
| Space RBAC and permission rules | Entry to the space and actions on governed resources | An effective permission rule must allow the requested action. |
| Workspace access | Visibility, authoring changes, sharing, and workspace configuration | view to inspect; manage to change drafts, settings, or sharing. |
| Repository access | Reading source context and contributing repository changes | Repository view for inspection; contribute for mutation and publication. |
| Connector access | Reading metadata, brokered API calls, and managed-resource changes | Connector execute for brokered API operations; connector edit for write-grant management or target changes. |
| Platform administration | Instance-global runtime, proxy, and rollout controls | A superadmin; security-sensitive profile changes also reject impersonated sessions. |
Workspace visibility is independent of repository access. A user may be able to view a shared workspace without being able to read its connected repository, or manage a workspace without being able to contribute to the repository selected for publication. The cockpit reports these as separate blockers.
Workspace grants can target users or teams and use view or manage. Space
administrators, the workspace owner, and explicitly granted managers can manage
the workspace. Repository and connector permissions are still evaluated by
their owning services.
Runtime Permission Profiles
Every authoring execution receives a server-resolved, immutable permission profile. The Runtime Inspector can show its effective tool risk, reviewer, writable roots, and allowed tools. The full profile also includes:
- sandbox mode and writable roots;
- network access;
- tool allowlists and denylists;
- maximum tool risk;
- approval policy and reviewer;
- permitted high-level operation capabilities and risk;
- whether side-effecting operations are allowed.
A request can be narrowed by the server but cannot expand the configured ceiling. Child work inherits the parent's authority or a stricter subset. Changing an administrative policy affects new executions; it does not silently expand an active execution's persisted authority.
The runtime permission profile is a logical authorization boundary for tools and operations. It is not the same thing as the generated-code validation sandbox described below.
How Tool Calls Are Processed
Pipeline Authoring exposes typed tools for activities such as repository reads, bounded workspace proposals, graph changes, checklist updates, catalog and standard lookup, package inspection, web research, registered commands, and contract-bound API operations.
For each call, Qarion:
- Resolves the tool from the current runtime and orchestration allowlist.
- Requires capability metadata and validates the structured arguments.
- Applies the active tool allowlist, denylist, risk ceiling, network policy, workspace scope, and resource permissions.
- Stops for an approval or exact authorization grant when required.
- Revalidates live authority immediately before an approved effect.
- Executes through the tool's bounded adapter.
- Redacts and bounds model-visible output, then records the durable trace.
Missing capability metadata, unavailable tools, unsafe network intent, and trace-persistence failures do not fall back to unrestricted execution. If a required trace cannot be recorded, the result is withheld.
External MCP tool providers are a separate platform feature. V1 space enablement permits read-risk tools only. Pipeline Authoring web research uses a stable Qarion facade, explicit consent, sanitized queries, bounded results, and one configured provider binding. One root-task grant can authorize bounded agent-decided follow-up searches during reformulation and decomposition, but never after plan approval or from a subagent. The grant expires after 24 hours, is capped at six distinct searches, and is invalidated when access or the provider binding changes. It does not grant network access to generated code, repository commands, sandboxes, or delegated workers. Administrators can review provider readiness in AI Ops.
Queries are sanitized before persistence and provider execution. Planning-stage searches prefer official documentation, while normalized snippets from every domain remain untrusted. Identical query fingerprints reuse durable evidence. Repeated needs that make no progress, quota exhaustion, unsafe input, provider failure, and malformed or non-public results stop the research loop without supplying invented facts to the plan.
Approval Types
Approvals are purpose-specific and cannot be substituted for one another.
| Approval | Authorizes | Important binding |
|---|---|---|
| Plan and diff review | The reviewed implementation scope and resulting changes | Approved plan, checklist, candidate, paths, and current draft state. |
| Tool authorization grant | One approved write-capable tool in a bounded execution unit | Session, plan, workflow, tool, primary path, related paths, and live issuer authority. |
| Repository-command approval | One registered repository command request | Command profile, arguments, purpose, directory, paths, repository, workspace fingerprint, runtime image, and network policy. |
| Sensitive-artifact approval | A protected workspace file or approval-gated Bash node | Exact content or command hash, operation, repository/ref, base version, target, approved plan, candidate fingerprint, and policy version. |
| API operation grant | One external API write or destructive call | Actor, session/workflow, connector, credential, egress profile, contract, operation/effect, scope, and canonical request hash. |
Repository commands use registered command profiles with fixed executables,
validated arguments, bounded environment variables, timeouts, and output
limits. Raw shell and command-forwarding executables such as bash, sh,
zsh, env, sudo, and xargs are not valid authoring command profiles. An
authored Bash pipeline node is runtime content; it does not grant Qarion a shell
during authoring.
Sensitive automation paths such as CI workflows, hooks, Docker/build files, scripts, shell files, and CODEOWNERS require their own review. Repository control paths, credentials and secrets directories, non-template environment files, and key or certificate material are blocked rather than approvable. Compiler-owned generated paths also cannot be moved or deleted directly.
Network Egress And Proxies
Qarion has two different proxy controls for authoring. They solve different problems and are not interchangeable.
Authoring Network
The shared Authoring Network policy controls approved network access for package fetching and supported authoring execution paths. Network-capable Docker work uses an internal, per-execution network whose only peer is the trusted proxy. Kubernetes installer egress is restricted to cluster DNS and the configured proxy endpoint. Generated-code execution itself has no egress.
Credentialless API Egress
An authoring API-egress profile is an instance-global routing policy attached
to an API connector. It contains a proxy origin, exact HTTPS host allowlist,
private-destination policy, and active state—not target credentials.
Only a non-impersonating superadmin with connector edit can attach or detach
that profile; a non-impersonating user with connector edit can issue or revoke
an exact API write grant.
During a brokered call, Qarion resolves the connector, active immutable contract, credential, profile, operation, and actor in the trusted process. The tool supplies only contract-declared parameters and bodies. It cannot select an arbitrary URL or method, set authentication or cookie headers, or retrieve the credential. Redirects are rejected.
Contract-classified reads do not need an API operation grant. Writes require an
exact, expiring, one-time grant. Destructive operations additionally require
CONFIRM {operation_key}. A grant is released if validation fails before any
OAuth or destination dispatch; once outbound dispatch begins, it is consumed
even if the outcome is uncertain.
Responses are bounded and secret, PII, and PHI redacted before a sample can be shown to the model. Binary or unsafe malformed XML bodies are not returned.
Generated-Code Validation Sandbox
Generated-code validation is not a general-purpose execution environment. It runs the exact candidate and trusted validation harness with bounded inputs, resources, time, output, and evidence.
- Docker is the local and development backend. Containers drop capabilities, prevent privilege escalation, use a read-only root filesystem and bounded temporary filesystems, and apply CPU, memory, PID, and timeout limits.
- Kubernetes is required when the generated-code sandbox is enabled in production. It uses a dedicated namespace, digest-pinned image, separate installer and credentialless execution service accounts, restricted Pod Security, admission policies, resource quotas, and default-deny networking.
- The trusted supervisor owns process output and result-file collection, demotes candidate execution, filters its environment, bounds output, and rejects unsafe or oversized result files.
- Candidate-authored exit codes, JUnit, and output are observations. They become authoritative only when tied to the exact candidate by platform-controlled validation evidence.
Sandbox validation ends before publication. Published Airflow or Dagster code runs in the deployment environment selected by the operator and retains that environment's own identity, secret, network, and runtime controls.
Audit And Data Handling
Pipeline Authoring records redacted workflow events, policy decisions, approval identities, validation evidence, tool lifecycle, operation receipts, and publication history. Public activity shows an allowlisted summary. Detailed redacted runtime events remain restricted to the Runtime Inspector and audit surfaces.
Prompts, raw provider reasoning, raw tool arguments and results, command output, authentication material, OAuth tokens, proxy URLs, and external response bodies are not copied into public activity. Broker audits retain identities, hashes, effect, timing, status class, size, truncation, and redaction categories rather than raw request or response bodies.
Web-research activity uses low-cardinality outcomes for proposed and executed follow-ups, cache reuse, no progress, and quota exhaustion. Query text, domains, tenant identifiers, and repository identifiers are not metric labels or public timeline content. The approved plan may display the normalized source cards so reviewers can inspect the evidence that influenced decomposition.
Troubleshooting Security Blocks
| Symptom | What to check |
|---|---|
| Workspace is visible but editing is blocked | Confirm workspace manage and repository contribute independently. |
| A tool is unavailable | Check the active permission profile, tool allowlist/risk, required resource access, feature readiness, and provider binding. |
| A previous approval no longer works | Compare the current plan, workspace fingerprint, repository/ref, candidate, paths, command or request hash, policy version, and expiry. |
| API operations are unavailable | Confirm connector execute, an active contract and credential, an active egress profile, allowed HTTPS destination, and network permission. |
| An API write grant is rejected | Confirm connector edit was used to issue the grant and that its actor, session, workflow, contract, operation, scope, request, and expiry still match. |
| Sandbox evidence is unavailable | Review AI Ops, sandbox backend/image/namespace readiness, network and cluster attestations, dependency policy, and the exact validation diagnostic. |
| Publication remains blocked | Resolve workspace/repository permissions, stale or missing validation, incomplete reviews, pending approvals, and every required publication section. |
Do not work around a security block by copying credentials into a draft, rewriting a command through a shell, disabling validation, or moving generated code outside the governed workflow.