1.15.27 — Remote agents and guarded AWS migration

2026-08-22

django-mojo now lets operators connect external AI clients through OAuth 2.1-secured MCP, optionally grant explicit full REST access, and manage or revoke those connections from Admin. It also adds exact-reference brownfield fleet provisioning and rehearsed, journaled preserved-EIP NLB handoff and rollback while preserving existing DNS, certificates, addresses, and data-plane resources.

Added

• OAuth 2.1 remote-agent access with PKCE, explicit consent, short-lived access tokens, refresh rotation, revocation, protected-resource discovery, and a stateless MCP endpoint available on every application node.
• Admin controls for enabling remote access, checking discovery, identifying each connection's access level, and disconnecting one or all agents.
• An explicit api scope bound to the REST API root. Clients may request tools-only, full API, or both; full API access is shown separately during consent and in Admin.
• Exact-reference brownfield AWS fleet provisioning that validates an existing network and data plane while creating only migration-owned nodes, load balancers, IAM, logs, and alarms.
• Preserved-EIP NLB handoff and rollback commands with immutable plans, mandatory rehearsal, one-AZ-at-a-time transfer, provider-state checks, and local plus versioned-S3 write-ahead journals.

Changed

• User-tier memories and caller-owned user-tier skills can execute directly on every Assistant transport, including MCP. Group, global, and other users' state remains approval-gated.
• Memory and skill writers are now advertised to MCP clients; model-spending reads and Assistant meta-tools remain hidden.
• Assistant web fetching now uses the shared SSRF-safe fetcher across browsing, documentation, redirects, and remote-client discovery.

Fixed

• Remote-agent grant listing and bulk revocation remain scoped to the exact registered resources, including installations with appended slashes or a changed public origin.
• Direct owner-state tool calls normalize arguments before authorization and retain an unsuppressed mutation audit trail.
• Brownfield discovery follows actual ElastiCache response shapes, and listener convergence validates complete forwarding contracts.

Security

• MCP tokens are confined to their exact resource and live grant. API-wide access requires the separate REST-root api scope and explicit consent; direct REST calls intentionally have the same reach as the consenting user's session and do not use Assistant approval.
• The shared fetcher refuses parser differentials, malformed authorities, private or unresolved destinations, unsafe redirect hops, and cross-origin credential forwarding.
• Brownfield apply uses a positive mutation policy. DNS, certificates, preserved-address association, secrets, storage data, databases, caches, networking, and teardown remain unreachable from ordinary fleet provisioning.
• EIP handoff uses a separate role and exact provider bindings. Canary request bodies and credentials never enter plans or journals; recovery retains only their digest.

Upgrade notes

• Apply the included account migration before enabling remote-agent access.
• Remote access remains off by default. Configure the canonical public URL and proxy the OAuth authorization-server and protected-resource discovery prefixes to Django before enabling it in Admin.
• Existing managed deployments are unchanged. Brownfield fleet preparation and EIP handoff use separate manifests, commands, credentials, rehearsals, and confirmation gates.
• Before a preserved-EIP handoff, configure the dedicated cutover role and encrypted, versioned journal bucket, then pass fleet readiness, database/cache probes, host and TLS canaries, and an exact-plan rehearsal.