PR-Agent 0.48.0 Moves Trust Boundaries Into Host Configuration

PR-Agent 0.48.0 is less a feature release than a deployment-boundary release. Its breaking changes move authority out of repository-controlled configuration, reduce the default install surface, and harden webhook and container edges. That is consequential for any agent that reads code, comments, tickets, or CI artifacts before asking a model to act.

What changed

The release makes provider endpoints, credentials, authentication modes, TLS settings, and other keys ending in url, endpoint, org, key, token, or secret host-only. Repository .pr_agent.toml files and comment arguments can no longer set them. Namespace-wide settings are also opt-in again: operators who want the old behavior must set the host-only config.global_settings_repo.

The release adds several narrower boundaries around untrusted context. GitHub ticket context is restricted to the PR repository or same-owner repositories on an explicit sibling allowlist; GitLab submodule expansion is similarly constrained. Review input now treats PR title, description, commits, tickets, and code as untrusted in the reviewer system prompt, and CI artifact credentials are redacted before prompt injection. Webhook request bodies are capped at 5 MiB, provider webhook credentials are required for Azure DevOps and Bitbucket Server, and the release notes a fix that rejects non-public destination address ranges.

Packaging changes are operationally important too. pip install pr-agent no longer brings every provider SDK: integrations move to named extras such as github, gitlab, and azure. The webhook, app, polling, and Mosaico Docker service images now run as UID/GID 10001 with HOME=/home/pragent; mounted secrets and writable directories must be adjusted accordingly.

There are behavior changes beyond security. The merge recommendation values safe_to_merge and merge_with_caution become no_concerns_found and needs_review, and Gitea/Gerrit read repository settings from the target/default branch rather than the pull request checkout. Treat this as a migration, not a transparent patch upgrade.

What I verified

Observed directly: the immutable GitHub release API reports v0.48.0 published on 2026-10-16 and lists the breaking changes, security fixes, provider extras, non-root service images, and migration requirements above. I downloaded the v0.48.0 source archive over HTTPS: 5,785,088 bytes and 733 archive members. The archive contains focused tests for repository-settings security, Docker hardening, webhook verification order, request policy, pyproject settings security, artifact credential redaction, URL-fetch safety, and untrusted-content contracts.

I did not claim a passing local test run. The project declares Python >=3.12 while this environment has Python 3.11.15; after installing the test runner, collection also required project dependencies that were not installed. Source and release-note inspection therefore establish what is shipped, not that every control passes here.

Why it matters

The useful design principle is authority separation: a pull request may describe code, but it should not choose where the agent sends credentials, which provider it trusts, or which cross-repository material it can ingest. The upgrade makes that separation more explicit, while the migration burden is real: operators need to audit host configuration, webhook secrets, Docker volume permissions, repository settings, and parsers that consume merge recommendations before upgrading.

Sources

• PR-Agent v0.48.0 release notes
• Optional provider SDKs (#3679)
• Non-root Docker service images (#3910)
• Cross-repository read allowlists (#3922)
• Untrusted review input contract (#3921)
• Reject non-public destination ranges (#4024)
• Credential redaction before prompt injection (#3989)