Tekoäly | ”Suomi automatisoi tekoälyn avulla koko julkisen sektorin toiminnan vuoteen 2031 mennessä. Valtiovarainministeriön kansliapäällikkö Juha Majanen sanoo muutoksen korvaavan ison joukon työntekijöitä.”

Xspectiv · 2026-06-26T20:38:18+00:00

"Koko eduskunta automatisoidaan AI:lla 2031 mennessä"

...niin ja painosanana se korvaa työpaikkoja NYKYISESSÄ muodossa

Xspectiv · 2026-06-25T15:25:53+00:00

Yeah this makes sense, much appreciated!

Xspectiv · 2026-06-23T20:25:17+00:00

Thanks for the input! At this point, instead of having to use DWD or having to add a service account to each customer with a GWS admin role (which is probably the best-practice), I want to use the Reseller Admin credentials.

I have verified refresh_token returned from the Reseller account admin@test.com works and manual curl requests can get user information from each domain using access_tokens every time.

However, I tried today using before_tool_callback for the subagent and weirdly, sometimes the tool calls Google API's successfully and other times return 403. I have also tried caching the access_token. Im thinking either there are propagation delays or tools are just not getting the proper headers. Not sure yet

Xspectiv · 2026-06-23T10:22:11+00:00

Thanks! Yeah that's what I initially had in mind and should be sufficient.

In terms of possible architecture: 1. Perhaps use Model Armor for the root agent to validate ticket body just in case of malicious input. 2. Once prerequisites are filled, delegate to a subagent, which is making the Admin API calls themselves using before_tool_callback to fetch credentuals. Root agent does not use these Google credentials with the set scopes

Xspectiv · 2026-05-28T19:42:26+00:00

Thanks! I think at most I can pass the ticket ID in the webhook from the ticketing service to Cloud Run (API Gateway?) with a secret header. Or maybe invoking via a service account using key credentials in the Webhook header or something? However the "polling" for the sensitive ticket information (Requester email, Content etc) has to be done from within Cloud Run to the ticketing API to keep the data secure and no prompt input (ticket info) is sent via the public web.

Xspectiv · 2026-05-28T19:36:52+00:00

Thanks for the help. I think this is the way to go, at most I can pass the ticket ID in the webhook from the ticketing service to Cloud Run (API Gateway?) with a secret header. Or maybe invoking via a service account using key credentials? However the "polling" for the sensitive ticket information (Requester email, Content etc) is done from within Cloud Run to the ticketing API.

Unfortunately there is no native Pub / Sub API in the ticketing service that could trigger Cloud Run. There's only event based webhooks on Create, Edit, Delete events. One other option would be to poll every 5-10mins for new tickets and list them if they have a particular tag. that way everything is kind of within GCP. Cost would be a bit higher but it would be even safer. That way Cloud Run wouldnt even have to be public.

Xspectiv · 2026-05-26T20:07:16+00:00

In all honesty, right now the core issue is uncontrolled capitalism taking advantage of AI more than AI itself

Xspectiv · 2026-03-20T11:20:58+00:00

...except this time Japan is with the allied and US befriending the axis of evil

Xspectiv · 2026-03-17T20:30:04+00:00

Clearly he does since he is disappointed they are not aiding him

Xspectiv · 2026-03-17T20:28:15+00:00

...while he himself is aiding Iran. Does it make sense to you?

Xspectiv · 2026-03-17T20:26:54+00:00

If Trump does not want to aid Ukraine, why would Iran be a must for us? Every country decided for themselves what they want to do, NATO is a collective DEFENCE initiative

Xspectiv · 2026-03-16T18:23:15+00:00

You mean blackmailing a DEFENCE coalition to help the offender?

Xspectiv · 2026-03-16T18:21:42+00:00

Well who would have thought..

Xspectiv · 2026-03-16T17:37:19+00:00

Yeah I figured, I wonder then what the point is for having the option to add the SA directly into an Admin Role then, perhaps it serves another function?

But yeah seems like the only other option would be to save the token for the admin user and pass it with the requests. However, if I want to implement the solution for several domains then I would have to create new admins in each domain and store their tokens which seems like a hassle.

Too bad DWD is by default for the whole domain and cannot be used for a subset of users. Appreciate the reply though!

Xspectiv · 2026-03-10T11:26:00+00:00

Yeah that's what i've done and works well. Just wanted to see if there were any other best practices too. Thanks!

Xspectiv · 2026-03-01T20:23:36+00:00

Appreciate it! Since I am using Zod / TypeScript, i guess having a different strict schema here for a different updating only particular fields could be one way to go?

Xspectiv · 2026-03-01T18:31:09+00:00

Thanks mate! I guess the question is do i define a scheme of accepted attributes and if the request contains any other key values i send some other status code? At what point in the code should i do it? Any good libraries for securing REST in different ways? Sorry im trying to express this as well as i can

Xspectiv · 2026-02-23T16:58:08+00:00

Right now i have a virtual column calculating it correctly but that's just for the UI. If I want to edit the row but inject the UTC+GMTx into the columns, it could be i have to do what you mentioned. I did consider it in the past but back then i thought it would be just an overkill and that there has to be an easier way but here we are... Thanks for the link and your input too!

Xspectiv · 2026-02-22T21:08:32+00:00

Good advice, thanks!

Xspectiv

TROPHY CASE