SECURITY / CERT-In CIAD-2026-0049
AI agents need limits.
Here is where Grantex fits.
An agent asked to review a merchant's documents should not also be able to export every customer record or release a payment. Grantex helps put that distinction into the API path.
Start small. Prove the boundary.
- Pick one read-only job.One owner, one API, synthetic records.
- Limit its access.A separate, short-lived grant and explicit destinations.
- Test the refusals.Wrong action, missing approval and a revoked grant must fail.
In this article
The problem is ordinary access, at agent speed.
CERT-In's Critical Advisory CIAD-2026-0049, issued on 15 October 2026, describes agents reaching systems beyond their assigned tasks. Exposed credentials, excessive permissions and reachable APIs gave them a way in.
A prompt saying "only read this case" is not a security control. The service receiving the request must enforce the limit.
Grantex handles delegated authorization: who allowed an agent to do what, until when, and whether that permission still stands. That limited permission is called a grant. Your application still enforces which records the agent can access.
Grantex supports parts of the advisory's recommendations. It is not a CERT-In certification, endorsement or complete compliance solution. These workflows are integration patterns, not evidence that every deployment has the controls enabled.
Read this case. Not the whole business.
A merchant-review agent needs to read a case and prepare a summary. Give it limited, expiring authority instead of a reusable administrator key. Request a separate grant for each run; this is a runtime integration choice, not automatic process isolation.
- 01Owner grants accessRead permission, intended API and an expiry.
- 02Agent requests a readIt presents the grant to the protected boundary.
- 03Access is checkedRight agent, right API, allowed action, still-active grant.
- 04API returns allowed dataEnforce tenant and case access; record the action and outcome.
Wrong action, expired or revoked grant? Deny before the protected operation. Do not fall back to a broader key.
In practice: cases:read does not itself mean "only case C-1042." The service must bind access to the authenticated tenant and permitted case. A scope label alone does not prevent bulk export.
A trusted gateway can redeem a vault credential reference and inject the upstream key without giving it to the agent. This helps only if the agent cannot read that key elsewhere or bypass the gateway.
Preparing a payment is not permission to send it.
An agent can assemble evidence and draft a recommendation. A sensitive operation needs a separate, authenticated human decision and a final check by the system that executes it.
- 01Agent preparesCollect evidence and draft the proposed action.
- 02Human reviewsAn independent, authenticated reviewer decides.
- 03Link the approvalBind it to this exact action; check who approved it and when.
- 04Executor validatesCheck the exact action, limits and replay state before execution.
No valid approval, or changed payment details? Keep the action blocked. The agent must not approve its own request.
See the related payment guidance in CIAD-2026-0046. This is an illustrative design, not a live merchant-activation claim. The merchant pilot remains sandbox-only.
Stop access without asking the agent to cooperate.
If an agent starts requesting unrelated records, an independently protected operator path should be able to withdraw its authority.
- 01Monitor flags activityConfigured alerts reach a responsible operator.
- 02Operator revokesRevoke the grant or use the emergency-stop control.
- 03Next action is checkedConfirm permission is still active. Refuse after revocation.
- 04Incident owner follows upPreserve evidence, rotate exposed keys and retest.
Revoking a Grantex grant does not revoke a stolen upstream API key. Rotate that key at its issuer and close direct access paths. Hash-linked audit records help check evidence integrity; they do not make storage undeletable.
What Grantex helps with. What your team still owns.
Selected advisory themes, not a replacement for the full advisory or your compliance assessment.
Least privilege and per-run identity
GRANTEXScoped, expiring grants; delegation that narrows authority.
YOUR TEAMIssue a grant per run. Enforce resource access and least-privileged cloud roles.
Exposed credentials
GRANTEXVault references can keep upstream keys out of agent hands.
YOUR TEAMScan history, builds and cloud configuration. Rotate exposed keys and block reuse.
Restricted network access
GRANTEXOpt-in source gateway restrictions and a Helm policy template.
YOUR TEAMDeploy and test a network-level deny boundary for each relevant workload.
Monitoring and evidence
GRANTEXAudit records, integrity checks and security-event integration points.
YOUR TEAMConfigure burst/bulk-read alerts, test delivery and protect retained logs.
Secure administration
GRANTEXTenant OIDC/SSO and separate privileged access paths.
YOUR TEAMEnforce MFA in your IdP, protect administration and remove dormant APIs.
Containment and response
GRANTEXRevocation, operator controls and exportable audit evidence.
YOUR TEAMInvestigate, patch, rotate credentials, retest and assess reporting duties.
The advisory recommends at least 180 days of logs. The separate 28 April 2022 CERT-In Directions require covered entities to securely retain ICT logs for a rolling 180 days within Indian jurisdiction and report specified incidents within six hours of noticing them or being notified. Confirm applicability with your legal and incident-response owners. A retention setting alone proves neither coverage nor location.
Available does not mean configured.
- EXISTING PRODUCT MECHANISMSGrants, delegation, revocation, current-authority verification, decision grants, vault references and audit records. Each requires correct integration and configuration; availability is not a test result for your application.
- NEWER OPT-IN SOURCE CONTROLSRestricted gateway origins, redirect refusal, TypeScript
rejectRedirectsand Helm network policy. Local synthetic gateway tests and chart checks passed. These additions are not in a published SDK release; no enforcing Kubernetes CNI was tested. Check release status for installed packages. - DEPLOYMENT AND ORGANISATION CONTROLSTenant-owned SSO/MFA, network enforcement, secret rotation, alert routing, log jurisdiction/retention, patching and incident response. Installing Grantex does not complete these. A Helm policy does not automatically protect Cloud Run or every agent worker.
Prove five things before widening access.
- The intended read succeeds. Return only permitted tenant and case data.
- A broader action fails. Try another tenant, bulk export and an unapproved write.
- Missing or changed approval fails. A changed beneficiary or amount cannot reuse an earlier decision.
- A disallowed destination fails. Test the actual network boundary and a redirect.
- A revoked grant fails on the next check. Confirm an operator receives the alert and can retrieve evidence.
Use synthetic records, no live financial effects, and record the revision, effective settings, results and responsible owner. An untested control stays open.
Primary references
- CERT-In CIAD-2026-0049: AI agents as attack vectors, 15 October 2026. Recommended actions A and B.
- CERT-In CIAD-2026-0046: payment and disbursement API threats, 9 October 2026.
- CERT-In Directions under section 70B, 28 April 2022. Clauses (ii) and (iv).