Bounded Autonomy: typed action contracts na consumer strani zaustavljaju LLM greške u enterprise softwareu

Što je problem?

U enterprise softwareu — CRM, ERP, internal tools, customer support platforme — AI agenti sve više izvršavaju akcije s posljedicama: ažuriraju zapise, šalju e-mailove, pokreću workflow-e, pristupaju različitim klijentskim workspace-ovima. Problem nastaje kad LLM pogriješi na način koji probija sigurnosne granice:

• Neautorizirane akcije — agent izvršava funkciju za koju korisnik nema permisije
• Malformirani requestovi — struktura poziva alata krši očekivani format, API puca
• Cross-workspace execution — u multi-tenant okruženju, agent dira podatke drugog klijenta
• Neovlašteno escalation — agent koristi alate koji zahtijevaju veću razinu privilegije nego što je korisnik odobrio

Klasično rješenje je “trenirati model bolje” ili “dodati guardrails u prompt”. Oba su probabilistička — model još uvijek može pogriješiti, samo manje često. U enterprise okruženju gdje greška može značiti GDPR prekršaj ili gubitak povjerenja klijenta, to nije dovoljno.

Rješenje koje rad predlaže

Rad predstavljen 17. travnja 2026. na arXivu predlaže deterministički sloj izvan modela:

• Typed Action Contracts definiraju eksplicitno koje akcije agent smije izvršiti, s kojim argumentima, u kojem kontekstu, i pod kojim preduvjetima
• Consumer-side execution znači da LLM ne izvršava akcije direktno — on generira strukturirani action request koji zatim consumer aplikacija validira protiv type ugovora prije bilo kakvog izvršavanja
• Ako request ne prolazi type check (pogrešan tip, nedostaje permission, krivi workspace), akcija se ne dogodi — bez obzira što je LLM “mislio”

Arhitektonski, ovo pomiče teret sigurnosti s probabilističkog modela na deterministički type system — statička provjera umjesto runtime molitve.

Kako izgleda u praksi?

Autori daju konkretne primjere iz enterprise okruženja:

Primjer 1 — Workspace izolacija:

UpdateCustomerRecord(customerId: CustomerId, fields: CustomerFields)
  requires: caller.workspace == customer.workspace

Ako LLM pokuša ažurirati kupca iz drugog workspace-a, type sistem to odbije prije izvršavanja.

Primjer 2 — Privilegije:

SendExternalEmail(to: EmailAddress, body: String)
  requires: caller.permissions.includes(SEND_EXTERNAL)

Model može sastaviti savršen e-mail — ako korisnik nema SEND_EXTERNAL permisiju, akcija puca statički.

Primjer 3 — Semantic constraints:

DeleteRecord(id: RecordId)
  requires: record.createdBy == caller || caller.isAdmin

Model ne može izbrisati tuđi zapis čak i ako mu se čini logičnim.

Zašto je to bolje od prompt engineeringa?

• Prompt engineering oslonjen je na to da model čita i poštuje uputu. Uvijek postoji šansa da model interpretira granično ili greškom prekrši ograničenje.
• Type contracts su stvar kompajler-level provjere. Ne ovise o ponašanju modela. Ako su pravilno definirani, greške klasa koje pokrivaju su nemoguće.

Trade-off je složenost implementacije. Type sistem mora biti pažljivo dizajniran da pokriva realne scenarije bez pretjerane ukočenosti. Rad uključuje primjere iz nekoliko enterprise domena (sales, support, HR) i pokazuje da je praktično izvodljivo.

Implikacije za AI tool building

Za developere koji grade enterprise AI integracije, rad daje konkretan dizajnerski patern:

1. Definiraj eksplicitno sve akcije koje agent smije izvršavati
2. Za svaku akciju napiši typed contract s preduvjetima
3. Neka model producira strukturirani action request, ne da direktno izvršava
4. Validacija prolazi kroz deterministički type checker prije bilo kakvog side-effect-a

Pristup se usklađuje s trendovima MCP-a (Model Context Protocol) koji također promovira strukturirane tool calls umjesto slobodnog execution-a. Ako se kombinira s MCP-om, rezultat je slojevita obrana gdje kako MCP tako i type contracts blokiraju različite klase grešaka.

Rad je preprint, ali ideja je dovoljno konkretna da timovi koji sad grade enterprise AI mogu odmah primijeniti principe — čak i bez čekanja formalne peer review publikacije.