Im Mai standen Tests vor dem Release im Mittelpunkt. Im Juni folgten neue Zugriffs- und Betriebsfunktionen. Feste Admin- und Member-Rollen weichen anpassbaren Permission Groups, Dashboards lassen sich jetzt mit genau den gewünschten Personen teilen oder schreibgeschützt veröffentlichen, und Channels sowie Drains leiten Benachrichtigungen, Approvals und Logs an externe Systeme weiter. Außerdem haben wir die integrierten Guardrails für Prompt Injection und Data Exfiltration geschärft, die Datenbank und die Runs-Tabelle um KI-gestützte Filter erweitert und Deployments so angepasst, dass laufende Runs vor dem Wechsel abgeschlossen werden.
Anpassbare Permission Groups
Teammitglieder waren bisher entweder Admin oder Member, jeweils mit festen Berechtigungen. Jetzt lassen sich eigene Permission Groups aus granularen, aktionsbezogenen Berechtigungen zusammenstellen und Teammitgliedern sowie ausstehenden Einladungen zuweisen. Jede Berechtigung ist einer bestimmten Aktion zugeordnet. So kann eine Gruppe Builds bereitstellen und aktivieren, ohne jemals Billing oder Teammitgliedschaften zu verändern.
# Composed from granular, action-level permissions
deployments.activate # promote a build to live
deployments.override # override deployment checks
connectors.view
budgets.view
# billing.manage and team.update left out on purpose- •Aktionsbezogener Zugriff: Bestimmte Aktionen wie
connectors.createoderapprovals.decidelassen sich statt einer pauschalen Rolle vergeben - •Gilt für Einladungen: Gruppen werden ausstehenden Einladungen zugewiesen, damit neue Teammitglieder vom ersten Tag an den richtigen Zugriff haben
- •Ownership übertragen: Ein Projekt lässt sich in den Team Settings an einen anderen Owner übertragen
Unter Team und Berechtigungen steht die vollständige Liste der Aktionen.
Teilbare Dashboards mit Zugriffskontrollen
Observability-Dashboards haben jetzt eigene Sichtbarkeits- und Bearbeitungsregeln. Ein Dashboard kann privat bleiben, für bestimmte Permission Groups oder das gesamte Projekt freigegeben oder veröffentlicht werden. Ein öffentliches Dashboard erhält einen geschützten Share-Link und einen Environment Picker. Damit können Personen ohne Connic-Account eine Live-Ansicht erhalten.
private only you, plus editors and view-all admins
groups members of specific permission groups
project everyone on the project
public anyone with the secure share link- •Ansehen oder bearbeiten: Lese- und Bearbeitungsrechte lassen sich getrennt vergeben
- •Öffentliche Links: Ein schreibgeschützter, tokenisierter Link mit Environment Picker kann mit Personen außerhalb des Projekts geteilt werden
- •An Gruppen gebunden: Die neuen Berechtigungen
dashboards.viewAllunddashboards.updatebestimmen, wer was verwaltet
Mehr dazu steht in der Observability-Dokumentation.
Channels und Drains
Wir können Projektaktivitäten jetzt an externe Systeme senden. Ein Channel sendet JSON per POST an einen kontrollierten HTTPS-Endpunkt und leitet Benachrichtigungen sowie Approval Requests dorthin. Drains übernehmen das kontinuierlich für zwei Streams mit hohem Volumen: Projekt-Logs und Audit Events werden gebündelt und fortlaufend weitergeleitet. Webhook Delivery lässt sich eigenständig einrichten; Slack, Teams und PagerDuty sind auf Anfrage verfügbar. Channels sind ein Enterprise-Feature.
POST https://hooks.acme.com/connic
Content-Type: application/json
X-Connic-Signature: <HMAC-SHA256 over "{timestamp}.{body}">
X-Connic-Timestamp: 1782864000- •Benachrichtigungen und Approvals: Projektbenachrichtigungen und Approval Requests lassen sich bis auf die Ebene einzelner Agenten an einen Channel weiterleiten
- •Log- und Audit-Drains: Drains streamen Projekt-Logs und Audit Events gebündelt an einen Endpunkt
- •Signiert und verifizierbar: Mit einem Signing Secret enthält jede Anfrage eine HMAC-SHA256-Signatur, die sich vor der Verarbeitung prüfen lässt
Schärfere Guardrails
Zwei der integrierten Guardrails lassen sich jetzt schwerer umgehen. Der Prompt-Injection-Guardrail normalisiert nun ähnlich aussehende Unicode-Zeichen und entfernt unsichtbare Formatierungszeichen, bevor die Prüfungen laufen. Damit wird Unicode Smuggling verhindert, bei dem eine Injection hinter Zeichen versteckt wird, die wie andere aussehen. Der Data-Exfiltration-Guardrail erkennt jetzt Base64-kodierte Datenblöcke in der Ausgabe und fängt damit Payloads ab, mit denen Daten in kodierter Form herausgeschleust werden sollen.
guardrails:
input:
- type: prompt_injection
mode: block
config:
sensitivity: high
output:
- type: data_exfiltration
mode: block
config:
allowed_domains: [example.com]- •Unicode Smuggling blockiert: Ähnlich aussehende Zeichen werden normalisiert und Formatierungszeichen entfernt, bevor die Heuristiken laufen
- •Base64-Exfiltration erkannt: Base64-kodierte Datenblöcke in der Ausgabe werden markiert, damit Payloads nicht kodiert nach außen gelangen
- •After-Block-Middleware überspringen: Setze
run_after_on_block: false, damit bei einem blockierten Input die konfigurierte After-Middleware nicht ausgeführt wird
Die vollständige Referenz steht in der Guardrails-Dokumentation.
KI-gestützte Filter
Eine Beschreibung der gesuchten Daten genügt, damit Connic den Filter erstellt. Die Runs-Tabelle und der Database Browser wandeln einen Prompt in natürlicher Sprache in einen Filterausdruck, einen Status und einen Zeitraum um, die weiterhin manuell angepasst werden können. Im Database Browser wurde außerdem der bisherige Raw-JSON-Dokumenteditor durch einen visuellen Key/Value-Editor ersetzt.
Prompt: orders over $100 that failed this week
Generates:
statuses failed
time range 7d
expression input.amount > 100- •Runs und Datenbank: Filterung in natürlicher Sprache für die Runs-Tabelle und den Database Browser
- •Direkt verwendbare Filterausdrücke: Prompts werden in dieselbe Ausdruckssprache übersetzt, die auch für manuelle Filter verfügbar ist, zum Beispiel
context.tier == 'enterprise' - •Visueller Dokumenteditor: Gespeicherte Dokumente lassen sich als Key/Value-Paare statt als Raw JSON bearbeiten; daneben lassen sich die Retrieval-Spalten sortieren
Die Query- und Filterreferenz steht in der Datenbank-Dokumentation.
Sicherere Deployments und durchsuchbare Logs
Bei einem neuen Deployment wird das alte nicht mehr sofort beendet. Das Deployment Draining wartet, bis laufende Runs im vorherigen Deployment abgeschlossen sind, bevor dieses stillgelegt wird. Neue und erneut ausgelöste Runs gehen direkt an das neue Deployment. So beendet ein Rollout keinen Run mehr mitten in der Ausführung. Projekt-Logs haben außerdem eine Volltextsuche erhalten und lassen sich nach Log-Nachricht, Quelle oder Agent-Name filtern. Ein partieller Index hält den Log Feed auch in stark ausgelasteten Environments schnell.
- •Rollouts ohne Run-Abbruch: Laufende Runs werden im alten Deployment abgeschlossen, während neue Runs bereits in das neue wechseln
- •Log-Suche: Finde eine Log-Zeile anhand von Nachricht, Quelle oder Agent-Name
- •Logsuche unter hoher Last: Ein partieller Index hält den Log Feed auch in großen Environments schnell
Weitere Verbesserungen
- •Weitere Testfunktionen:
expected_tool_call_orderprüft, ob Tools in einer bestimmten relativen Reihenfolge aufgerufen werden. Default-mocksauf Dateiebene vermeiden Wiederholungen innerhalb einer Testdatei - •Connic Skill per CLI: Führe
connic skillaus (oderconnic init --skill), um den Connic Skill zu einem Projekt hinzuzufügen, damit der KI-Coding-Agent den Connic-Konventionen folgt - •Erweiterte Public API: Environments, Deployments, Verbindungen, Channels, Audit Logs, Judges, Retrieval Systems und Approvals sind jetzt über einen API-Key erreichbar
- •Budget-Gruppierung: Die Budgetnutzung lässt sich nach Agenten oder KI-Modell gruppieren und zeigt so, wo sich die Kosten konzentrieren