代理框架與安全
GitHub Agentic Workflows 0.88.4 Extends Data-Flow Policies to GitHub App Authentication
The new release automatically generates data-flow integrity and confidentiality policies for agentic workflows using GitHub App identities and adds sensitivity controls for trusted enclaves. Some isolation architecture changes exist only in recently merged main-branch code and should not all be treated as features delivered in 0.88.4.
GitHub published the technical summary for Agentic Workflows 0.88.4 on September 7. Rather than adding more models, the update focuses on strengthening policy boundaries governing agents’ access to tools, networks, and repository data in GitHub Actions. The most consequential change is that workflows authenticated through a GitHub App can now automatically generate DIFC (data-flow integrity and confidentiality) policies. Previously, teams using an App instead of a personal access token could still need to handle additional rules governing data sources, output destinations, and trust levels.
The release also adds more granular sensitivity settings for trusted enclave workflows, fixes routing issues affecting Pi/Anthropic traffic passing through the Agentic Workflow Firewall, and corrects the resolution of root-relative paths after importing a local manifest. When the OTLP authentication secret is empty, the system also no longer attempts to export telemetry, preventing large numbers of ineffective failed requests. The `add` command now recognizes `aw.json` projects, eliminating the need to recreate configuration when adding workflows to existing projects.
These changes merit attention from platform engineering teams because `gh-aw` is not merely a prompt wrapper: its compiler converts Markdown workflows into Actions YAML and manages tool allowlists, network restrictions, and safe-output operations. Errors in policy generation can therefore directly change which data an agent may read or transmit.
GitHub also said that Cloud Hypervisor microVM migration, dynamic enclave delegation, and repository-level enclave policies have entered the queue of recently merged changes; these items should not be conflated with the contents of the stable release. Users upgrading should still pin the CLI version, recompile `.lock.yml`, and compare the resulting permissions, network destinations, and safe-output status. In particular, outputs rejected by policy are being marked as `skipped` rather than `failure`. If monitoring determines whether an agent completed its task solely from the workflow’s overall success status, it may miss writes that were never actually performed.