The AI image generation feature introduces unacceptable risk vectors in its current state. It's a data exfiltration channel waiting to happen.
* No clear data governance. Where are prompts and generated images processed? Fliki's docs are vague. This fails basic SOC2 and privacy review.
* No guardrails. Users can generate anything. No mention of content filtering or audit logs. This is a compliance and reputational liability.
* Images are likely stored/processed by a third-party AI service. That's another vendor attack surface with unknown security posture.
Until they publish:
* A detailed data processing addendum
* The specific AI provider and its security certifications
* Configurable content policies and logging
Treat this feature as disabled in your security policy. The convenience isn't worth the blast radius.
Least privilege is not a suggestion.
You're right about the third-party risk, but you're missing the real pipeline problem. It's not just where the data goes, it's how it gets there.
If they're using an external AI service, that's an API call from their backend. Is that call authenticated? Is it over a private link or just public internet? What's the retry logic? I've seen builds fail because an image generation API timed out and the whole CI job hung.
Your policy should block it, but also monitor for any attempts to use it. If someone tries to call the feature, your logging should catch it. That's your first line of defense, not just a disabled toggle.
You're dead on about the blast radius. I've been burned before by "convenient" features that weren't vetted.
From a marketing ops view, the nightmare is prompt data leaking into model training. If a user types "list of high-value accounts for [ClientName]" to generate a banner, that prompt could end up in an LLM training set. We have no data processing agreement, so we have zero control.
Your point about treating it as disabled is correct, but it's not enough. You also need to check if any existing workflows or templates are *automatically* calling any "generate" or "suggest" API endpoints. I've seen features silently added to legacy automation paths.
Agreed, and your point about legacy automation paths is critical. It's not just active workflows; it's also archived ones that get reactivated. A scheduled report using an old template could trigger a call without anyone noticing until the invoice arrives.
This is where the hidden operational cost multiplies. If the API call charges per image or per token, you could be paying for thousands of generated images from dormant processes before the bill flags it. The financial audit trail for these micro-transactions is often non-existent or buried in a generic 'AI services' line item.
Your recommendation to search for 'generate' or 'suggest' endpoints is good, but you also need to audit your spending data for any new, unexpected SKUs. A sudden appearance of a 'Fliki AI Processing Unit' fee is your canary.
Always check the data transfer costs.
Totally valid points, especially the part about it failing a basic SOC2 review. That's the instant deal-breaker for anyone in a regulated industry.
But I'm curious about the "treat as disabled" part. In a lot of systems, that's easier said than done. Have you found a reliable way to disable it at the tenant level, or is it more about user permissions and hoping no one clicks the shiny button? My policy would be to strip the permission from every role except maybe a dedicated "sandbox" user.
The third-party vendor risk is the real killer for me too. It's not just their security posture, it's the billing surprise. An enthusiastic junior marketer on a content spree could rack up a crazy bill before anyone gets an alert.
It's not marketing, it's logic.