Insecure Integrations: The Actual Attack Path

The threat briefing spent forty minutes on jailbreak strings. The incident, when it came, was a webhook the SI had left open so the planner could receive tool results. The webhook believed any JSON that arrived with a shared header. An outsider posted a result the model had never asked for. The connector wrote it. The model was a spectator.

Insecure integrations are the actual attack path on departmental agents. Not because models are safe, but because connectors hold verbs, secrets and trust. A next-token predictor without a connector is a parrot. A connector without a model is still a door.

This teardown is for CISOs on 17 August 2026. Not legal advice. It is the unglamorous cousin of the write-access threat model. Draw the wires. Assume the model is hostile or absent. Ask what still moves.

Prcept will refuse open inbound webhooks and shared pool accounts. If your diagram needs them for the demo, the demo is the finding.

The wires that matter

Outbound tool calls: TLS, audience-locked tokens, allowlisted destinations, no open redirect through a helpful HTTP tool.

Inbound callbacks and webhooks: authenticated, idempotent, bound to a request id the connector minted. No shared static header. No any JSON.

Identity inheritance: the 2009 application pool, the officer SSO cached, the vendor jump. Integrations fail here more than in the model.

Data planes: queues, object stores, embedding APIs. If a worker can read the queue, that worker is in the threat model.

Egress you did not draw: licence, telemetry, crash reports, anonymous analytics. Companion pieces exist because this wire keeps growing back.

Trust boundaries the model cannot save

If the connector trusts the model's text to build a SQL string or a URL, you have injection that does not need a research name. Parameterise. Allowlist. The model outputs an identifier, not a query.

If the connector trusts an inbound body because only the model knows the correlation id, print that id from a CSPRNG and sign it. Do not use a counter. Do not use the citizen's ticket number alone.

If the connector retries forever, you have a write amplifier. Bounded retries, idempotency keys, dead-letter that a human reads.

Integration anti-patterns we still sign off in UAT.

Wire	Anti-pattern	Replacement
Webhook in	Shared header, any JSON	Signed, bound to minted request id
HTTP tool	Open URL from model text	Allowlist of hosts and methods
DB tool	Model-authored SQL	Stored procs / parameterised verbs
Queue	Unsigned messages, shared consumer	Signed, scoped consumer identity
Telemetry	Full prompt abroad	Hashes, India, or off

The diagram test

Ask for a diagram that still makes sense if you white-out the model. Every remaining arrow is an integration. Threat-model those arrows as if a junior contractor owns one end — because one day they will.

Ask which arrows can move a register if the model is offline. Those arrows are your real agent. They need the grant table, the secrets design, and the pentest plane.

Ask which arrows leave India or leave the gap. Write them. Unlisted arrows are findings, not features.

• No open inbound.
• No model-authored SQL or URLs.
• No shared pool identity.
• No unsigned queue.
• No undrawn egress.

When the wire is the incident

A forged webhook that changes a register is an attack on an application. A telemetry channel that ships personal prompts is a leak or a transfer. Map effects to existing CERT-In types. The tactic is insecure integration, not a new statutory code.

Preserve the wire logs. You will need request ids, signatures that failed, and destinations. That is why redact-at-source still keeps ids.

Fix the wire before you fine-tune the model to be more careful. Carefulness is not a signature check.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

We only integrate through the vendor's iPaaS.

Then the iPaaS is in the threat model. Who can publish a flow? Where do secrets live? Where does the log go? A brand is not a boundary.

mTLS makes webhooks safe.

mTLS authenticates a peer. It does not validate that this body belongs to this request id. Do both.

The model is inside the trust boundary.

The model is a confused deputy waiting to happen. Put the boundary at the connector.

Drawing egress will delay go-live.

Undrawn egress will delay you longer, after the first residency question or the first leak. Draw it this week.

A two-week wire audit

White-out the model. Hunt arrows.

1. Day 1–3: diagram every inbound and outbound path, including telemetry and licence.
2. Day 4–5: kill open webhooks and model-authored SQL/URLs.
3. Day 6–7: split identities off the 2009 pool.
4. Day 8–9: sign queue messages; bound retries.
5. Day 10–12: prove egress list with packet evidence.
6. Day 13–14: tabletop a forged callback. CISO signs the diagram.

How this shows up in the file

Subject: Integration diagram — agent [name] — model white-out.

Arrows: [list]. Inbound authenticated with [method], bound to minted request ids. No model-authored SQL or open HTTP. Identities: [not the pool]. Egress: [list], evidence dated. Forged-callback tabletop: [date]. Effects map to existing CERT-In types. Not legal advice.

An arrow that is not on this page is unauthorised.

White-out the model

If the diagram only makes sense with the chatbot in the centre, you have drawn a demo. White-out the model. Every remaining arrow is an integration. Those arrows are the agent. Threat-model them as if a junior contractor owns one end.

A brand-name iPaaS is not a boundary. Who can publish a flow, where secrets live, and where logs go are the questions. mTLS authenticates a peer; it does not bind this body to this request id. Do both or do not take inbound callbacks.

The model does not get a browser and does not author SQL. Allowlist hosts. Parameterise verbs. Unsigned queues are webhooks with extra steps. Draw egress this week, including telemetry, or inherit it as a finding later.

This article is informational field guidance for Indian public institutions, not legal, procurement, security-accreditation or engineering advice. Confirm against the current Gazette, GFR, GeM term, CVC instruction, CERT-In direction, DPDP text, departmental manual and your counsel before you file it.

How to fail this before citizens do

“Insecure Integrations: The Actual Attack Path” is a path problem. A P4 Security/CISO should be able to name the tool, the identity, the secret and the egress that would make “AI integration security risk” real. If the only control is a network diagram from last year, you have a story, not a threat model.

The chat window is a decoy. The blast radius lives in the connector, the webhook, the shared pool account and the egress you did not draw. Air-gap is not automatically secure. Prompt injection is not a conference joke when the agent can write a ticket. CERT-In still wants specified logs in India and incidents on a six-hour clock. Write those clocks into the runbook.

1. Red-team the write tools, not only the chat UI.
2. Kill undeclared outbound paths on staging.
3. Redact personal data from logs you will actually keep.
4. Scope a pentest that includes RAG and connectors.
5. Cap metered spend so a loop cannot empty a budget.

Close this loop before the next CAB

Put “Insecure Integrations: The Actual Attack Path” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P4 Security/CISO, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “AI integration security risk” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.

What must be true before you file this

If “Insecure Integrations: The Actual Attack Path” is only a heading, it will not survive a file inspection. A P4 Security/CISO should be able to attach one artefact that proves “AI integration security risk”: a log export, a clause, a scored row, a dated notice, or a refusal rule.

Write three dated sentences: what was decided, who owns it, and when it will be re-checked. Unsigned sentences are souvenirs. Dated sentences are controls.

• Name the owner of “AI integration security risk” inside the institution.
• Attach one artefact a stranger can open next year.
• Revisit when the model, the notice, or the SI changes.
• Do not treat a vendor slide as evidence.

What the next file must contain

“Insecure Integrations: The Actual Attack Path” earns a line in the noting only if a P4 Security/CISO can attach proof of “AI integration security risk.” A heading is not proof. A vendor slide is not proof. A workshop photograph is not proof.

Write three dated sentences: what was decided, who owns it after the next posting order, and when it will be re-checked. If you cannot write the three sentences, you are not ready to buy, to sell, or to go live.

Leave unsourced percentages out of the note. DPDP is not a blanket localisation statute. The November 2025 AI governance text is guidance, not an Act. CERT-In’s 28 April 2022 directions still set specified incident and log clocks. A PAC, when lawful, lives in GFR Rule 166.

• Name the designation that owns “AI integration security risk.”
• Attach one artefact a stranger can open next year.
• Record the instrument you are actually using.
• Revisit when the model, the SI, the notice or the posting changes.