Notifications
Clear all
Topic starter
01/07/2026 3:54 pm
TL;DR: Abnormal says pairing AI-native development with a reusable integration DSL helped cover more than 85 integration requests across platforms like Office 365, Okta, Workday, ServiceNow, Salesforce, OpenAI, Claude, and Copilot, while shipping new platforms at roughly 5 to 6 times the prior rate. The governance question is not coding speed alone, but how reusable identity, auth, and ingestion patterns are controlled as integration volume scales.
NHIMG editorial — based on content published by Abnormal AI: AI-native development and reusable DSLs for integrations
Questions worth separating out
Q: How should security teams govern AI-assisted integration development?
A: Security teams should require AI-assisted integration work to be expressed through reusable specs, templates, or control contracts before it reaches production.
Q: Why do reusable integration patterns matter for IAM and NHI programmes?
A: Reusable patterns matter because integrations repeatedly create identity objects, including API credentials, service accounts, and external access paths.
Q: What do teams get wrong about AI speeding up integration delivery?
A: They often treat speed as the main outcome and miss the governance effect of reuse.
Practitioner guidance
- Catalogue every integration pattern as a governed template Define canonical templates for endpoints, authentication, pagination, and ingestion before teams create new connectors.
- Tie AI-generated code to a reusable spec layer Require AI-assisted integration drafts to be produced against a DSL or equivalent contract so the output can be reused, tested, and reviewed consistently.
- Review connector permissions as part of access governance Treat every SaaS integration as an identity object with scope, ownership, and offboarding requirements.
What's in the full article
Abnormal AI's full article covers the implementation detail this post intentionally leaves for the source:
- The reusable DSL structure for defining endpoints, auth, pagination, and ingesters.
- The workflow where AI assists with one-pagers, TDD, test plans, and first-pass implementation.
- The operational reason the team says reuse compounds across multiple product areas.
- The specific ways Abnormal AI applies the pattern across integration requests and shipping velocity.
👉 Read Abnormal AI's analysis of AI-native integration delivery and reusable DSLs →
AI-native integration DSLs: what it means for IAM teams?
Explore further
01/07/2026 9:41 pm
Reusable integration logic is becoming an identity governance control, not just an engineering efficiency. When auth, pagination, and ingestion patterns are encoded once and reused, the organisation reduces drift across connector builds. That lowers the chance that each integration invents its own access behaviour, but it also means the DSL becomes a governance boundary for how identities reach data and APIs. Practitioners should think of connector standardisation as policy enforcement by design.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How do organisations know an integration DSL is actually helping governance?
A: Look for fewer one-off connector designs, faster review cycles for new integrations, and lower variance in how credentials and ingestion rules are implemented. If the DSL exists only to accelerate coding but each build still needs bespoke security handling, it is not improving governance in practice.
👉 Read our full editorial: AI-native integration DSLs are changing how security teams scale
