Laravel A1 Pdf Sign Laravel Package

Product Decisions This Supports

• Build vs. buy for Brazilian digital signing. A1 certificate handling, PDF signing, and validation are compliance-sensitive and certificate-format-specific; this package removes that from your roadmap. 3.2.0 keeps extending the "buy" case by absorbing an adjacent build: exposing document read/sign actions to AI agents.
• Whether to ship an agent/MCP surface at all. 3.1.0 gated agent tools by disk; 3.2.0 gates them per document through your existing Gate. That reframes the question from "do we build a custom authorization layer for AI document access?" to "do we write two gate definitions?" — a much cheaper yes.
• Authorization as a product requirement, not an engineering detail. Ability::Read and Ability::Sign let you express real policy — "a customer may sign only their own contract" — in the place where policy already lives. This supports compliance review, security sign-off, and customer-facing commitments about what an assistant can and cannot touch.
• Risk posture on agent autonomy. Two deliberate defaults shape the risk conversation:
  • Fail-open abilities. An undefined ability allows access, so 3.2.0 is a no-op until you define gates. Good for adoption and backwards compatibility; a finding for anyone assuming "secure by default."
  • Approval is still requested when the gate will refuse, and the user is told it will be refused. This is a UX decision worth evaluating: it avoids silent failures but surfaces the refusal twice.
• Auditability and information leakage. The gate is consulted before the document is opened, so a refused user cannot probe for the existence of a path. That is a defensible answer to a security questionnaire and should be captured in your threat model.
• Cost and availability guardrails from day one. agents.max_bytes (50 MB default, checked from disk metadata before a byte is loaded) is the limit on what a model can name. It caps memory exposure per agent call, which is the number you need when modeling hosting costs and blast radius.
• Roadmap sequencing. If you already ship 3.1.0 agent tools, 3.2.0 is a small, high-value increment (per-document policy). If you have not adopted agents, this release is a reason to revisit the feature — not a reason to adopt it blind.
• Operational readiness for remote agent clients. The guide now covers throttling the MCP route and Mcp::oauthRoutes() for remote clients, plus when to use laravel/mcp's ToolSearch grouping (and why the package's own two-tool server doesn't). Rate limiting and OAuth are the two gatekeepers before any external assistant can touch contracts.
• Use cases this unlocks: customer-facing "sign this contract" assistants, internal contract-ops copilots that read a document and route it for signature, and support flows where an agent answers questions about a specific signed PDF.

When to Consider This Package

• You operate in Brazil or with ICP-Brasil A1 certificates. Signing, validating, and certificate handling are the core; everything else is a bonus.
• "Who may read or sign this document?" already has an answer in your app. 3.2.0 assumes Laravel Gate/policies are your source of truth. If so, integration is two definitions. If authorization lives in a separate service, an external ABAC engine, or tenant middleware rather than gates, you will bridge it yourself.
• You want AI agents to touch documents but are unwilling to write document-level authorization. This release is precisely that: reuse the gate you already have instead of building a new permission model.
• You have a security review process that will tolerate fail-open defaults if documented. Plan to define both abilities and add a test asserting refusal behavior before you enable agents in production — treating "undefined = allowed" as an explicit, tested decision rather than an inherited default.
• You can absorb a silent configuration change. max_bytes applies even to a config published under 3.1.0 (a missing key means the 50 MB default). Set agents.max_bytes explicitly — or null to preserve 3.1.0 behavior — as part of the upgrade, and audit for documents above 50 MB that agents must reach.
• You are already on 3.1.0. Read UPGRADE.md#from-310-to-320; the release is additive, but the size limit and gate semantics are behavior, not just configuration.
• Look elsewhere when: you need qualified/A3 certificates or HSM-backed signing, you need a full e-signature workflow product (envelopes, multi-party sequencing, long-term archival, court-grade audit trails) rather than a signing library, you require deny-by-default authorization out of the box, or you have no agent ambitions and no use for the MCP surface.
• Look elsewhere (for now) when: you need agent tools that operate across dozens of tools where ToolSearch grouping matters — the package's own server deliberately omits it at two tools, so a many-tool deployment puts that composition on you.

How to Pitch It (Stakeholders)

• To executives: This release closes the "can an AI assistant read or sign a customer's contract?" question using the permission system we already have. Per-document authorization is written once, as a gate, and the assistant inherits every rule we enforce in the UI — including refusals, which the user sees before the action is attempted. We also get a hard ceiling on what an agent can load (50 MB by default) and documented guidance for throttling and OAuth on remote connections, which is what an auditor or enterprise customer will ask about.
• To engineering: 3.2.0 adds Ability::Read and Ability::Sign gate definitions to the agent tools; the gate is checked before the file is opened, so refusals don't leak path existence. Two things to action: (1) abilities are fail-open — an undefined ability allows, so define both and add a regression test for refusal; (2) agents.max_bytes defaults to 50 MB and applies even without a republished config — set it explicitly, or null for 3.1.0 parity, and confirm the disk metadata path is available on your driver. The rest is additive: docs on throttling the MCP route, Mcp::oauthRoutes() for remote clients, and ToolSearch grouping trade-offs. Upgrade path is documented; quality signals are strong (233 tests, PHPStan max, 100% type coverage, suite green with both SDKs removed, plus a live-model scenario covering reads, refusals, and the approval flow).
• To security/compliance: Authorization is delegated to the application's gate rather than a package-internal ACL, authorization happens before document access, and file size is bounded from metadata before any bytes are read. The compensating control you must add is explicit gate definitions, since undefined abilities permit by default — we should treat that as a required deployment checklist item, not an optional hardening step.